不就是一个 sql 吗？？

Map data = selectOne("select id, title limit 3")
JSONUtil.toJSONString(input);

我是用 sql 写的，代码量就跟你不相上下了，甚至还少一些。

java 也有框架可以实现这种写法，我只是懒得去给你找了。

@lizuoqiang 还有，任意 IO 资源，java 不可以吗？ 还重点说明一下。真是服了。

@lizuoqiang 还有，麻烦你 把我的帖子全部看完整，我一直都是在 跟另一个人说话，告诉他 语言之间没有什么大的差异，基本上都能做到。

是你一直在跟我杠，非要说 php 简单吧？？

我是真的 明白了，为什么会有 “php 是世界上最好的语言” 这句调侃了

真是重复啰嗦，先解码成 json ，再转成 json 字符串。

你看看 java 怎么做的。

Map input = selectOne();
return JSONUtil.toJSONString(input);


而且你的这个例子 并没有 展现出，你刚才说的那种语法

@lizuoqiang 简单点。

数据库是这样的：

id name
1 zhangsan
2 lisi
3 wangwu


你用你引以为傲的 php ，写个例子出来，把这个数据 查询到一个变量里，然后转成 json 返回给前端。

你写一个，我也写一个，我用 map ，你用你引以为傲的 php ，最后对比下 差异有多大，可以吗？？？

@lizuoqiang 还有，不要开口闭口就杠精，不想争论就别说话。 想争论 就好好争论。 你最后发的这个例子就是没头没尾。 连赋值都没了

@lizuoqiang 你完整的写下来，我看看。 你最后发的这个例子，没有赋值的步骤。

@lizuoqiang 这种方式，你打算怎么动态？ 如果直接写死，其他语言也都可以


每个程序都有的字符串转实体的函数(`{"id":0, "name":"xxx"}`)

5 年前，我刚接触 maven 的时候，也是这样想的。现在感觉 这种包管理工具 是真神，不知道哪个天才发明的。

@l00t 单元测试不是给你自测用的，不然你写个 main 方法不也可以解决问题吗？ 或者用 postman 跑一下不也可以？

单元测试 是 你合并代码前，检查整个仓库用的，如果你改的东西 对别的地方造成了 bug ，那么在这个阶段 会立刻被发现。

配合 CICD ，在你提交 PR 的时候就可以做一个初步的 自动化测试。 你以为单元测试 只是在本地跑一下自测，就算影响了别人，也没人知道，但是实际上 单元测试 每次都应该是 全部跑一次的。 你影响了别人，别人的单测就会挂。 此时就会暴露出问题。

如果单元测试只是用来自测的，还能活到今天？ 早就被抛弃了。

CICD 搞起来，pull request 搞起来，单测规范起来，必须要写完整的测试用例。

然后 如果有可能的话，不要用 mock ，直接跑真实代码，就直接操作（测试 /开发库）的数据。

说白了，单元测试就是针对 具体的某个方法，做一个完整的黑盒测试。 如果你们没执行到这个力度，那确实可以不玩。

这一套下来，你看看，测试阶段 bug 量会少多少。

你只看到了单测费力，但是没看到改 bug 的时间 被缩短了吗？ 如果没，那只能说明你们的单测没执行到位。

java:

public class Demo {
public int id;
public String name;
}

go:

type Demo struct {
id int,
name string
}


php:

class NewsMapper {
public $id=0;
public $name="";
}

请问 更方便在哪？？？

你说 php 更方便，应该是说的这种把？

$news=new NewsMapper();
$news->name=”xxx”;
$news->id=xxx;

但是这跟 map 有啥区别？

go:

news := make(map[string]string)
news["id"] = 0;
news["name"] = "xxx";

java, c# 我就不写了。。。 都差不多。

NIO 应该不是快，而是用较少的线程，可以实现以前较多线程的并发量，并且对资源的占用 少了很多。

以前是一个连接一个线程，并发上来以后，线程会特别多。NIO 是 少量线程 处理 大量连接。
以前一个连接进来后，只要数据没有传输完成，这个线程就会一直停在这，不能释放。NIO 是 用一个线程去处理所有连接，有数据进来 才会通知业务线程去处理。收到多少数据就读多少，读完就释放了。 不会一直停在这。 对资源的利用率更高。

所以，在面对高并发的时候，NIO 更省资源，换句话说，同样的资源下，NIO 可以处理更多的并发， 这也是为什么一提到 NIO 总是说 他的并发高。

NIO 快的说法，我还是第一次听说。

@brader 这种写法 任何语言都支持，go 可以用 map ，java 也可以，c#也可以。 只是维护起来 要把人搞死，所以没人用。

相反，你在 php 里用实体 也是可以的，只是 php 基本上面向快速建站，所以很多为了后期维护而存在的规范，在 php 里都基本上不被重视。

很好奇，php 如果要返回 json ，不需要实体吗？ 将参数传给 service 不需要先封装到实体里面吗？

如果你在 php 里用的是 map ，那当我没说。

并发问题就是加锁，没别的

其实 redis 也有持久化能力的，之所以不只用 redis ，是因为 redis 的定位就是 内存数据库，他的设计初衷就是作为一个缓存而存在，并不是作为数据库的。

而你这个项目，从使用的角度来看，跟 redis 没啥区别，我建议你 后面可以在 查询方面 下点功夫，将查询能力丰富起来，这样就可以去打 redis 了

感觉你给自己挖了一个大坑，一上来就给这个项目定位了 redis+关系型数据库的 优点结合体，只用这一个就解决问题。

但是关系型数据库的作用，你一开始就想错了，他并不是 redis 的补充，反而 redis 是关系型数据的补充，它弥补的是关系型数据库查询慢，并发低 的问题。

关系型数据最大的优点就是，他一开始就是为了持久的储存数据而 开发的，并且功能丰富，操作灵活（得益于 sql ），起码就目前而言，关系型数据库是 储存数据的不二之选。


所以，我再次建议：

你就干脆把他当做 redis 的竞品，而不是 redis + 关系型数据的优势结合，想办法做的比 redis 更好用， 尤其是丰富查询能力。

因为关系型数据库的优势，不可能被替代的。如果有，那肯定不是 key-value 。

@Vegetable
@basefas

好的，非常感谢

需要等结果的场景，不适合用异步。 异步只适用于不需要等结果的场景，主要是为了快速响应的。

而且你这种情况，对顺序也有严格的要求吧，你可能需要等 A 接口返回了，用 A 接口的返回结果去执行下一步 调 B 接口，用 B 的返回结果调 C 接口对吧？ 如果是这样的话，那多线程的意义就更是彻底被玩没了， 反正都要等了为什么还要用线程？

如果不需要等，对顺序没有任何要求，只要调了就行，那或许还可以试试。但前提是 平常的压力之下，这些三方接口的处理速度必须要 > 生产速度，务必保证线程池里不会挤压任何任务。 让线程池 只用于应对 突发流量，保护三方接口不会被压垮（传说中的削峰）。

线程池其实就是一个内存级别的消息队列

你现在最好的情况是 做横向扩展，在双 12 当天加机器，同时做一下网关层的限流