@ChristopherWu 前提写进去的食个完成的 http，不然后端也没法解析

看来没人用这种显示器了

@guisheng NIO 的 httpclient+队列吧，编写起来也不太麻烦，毕竟不是 golang

@Mitt 对，这些都看了，我的意思是 PHP 写日志就算优化的写也只能等到一个 request 完后一次性写入，而不能做到像其他技术栈比如 go java 那样等到积累到了一定的大小再 flush，换句话说，qps 大了 PHP 写日志的次数远大于其他技术栈

@liuxey telnet 懂，redis 协议确实不了解，现在知道了

@nieqibest 装 X 犯太多了，这又不是知乎

@wangbenjun5 php 那些框架都是直接写的

多大年龄就飞蚊症了？

@cxshun 但是如果 id 值比较离散呢，10 10000 1000000 呢，这种恐怕一个叶子节点很难包括在一起，不走 root 怎么个搜出来呢

@Philyu 我的理解会把索引的 root 加载到内存，每次从 root 向下找，1，2，3，4 分别走四次 root，分别往下找，如果欧优化的话一次找到 1，2，3，4 就不再走 root 找了，这样理解对吗

@Philyu 意思还是查索引树查 4 次，io 看情况，一般挨着比较近就一次 io 搞定了

广告都打到这了🤦‍♂️

我就知道这种问题肯定会吵起来，都是打工的何必呢

为什么改成国产

这么多年了没人能量化程序员的工作量

@lvsshuttao 有没有想过这些人也是从基层做起的

@micean 这个本质上确实是 io 多路复用的原理吧，开起来挺方便的，vert.x 不太熟，netty 到是经常用，我一开始想的是用 netty 封装个 httpclient，但是感觉搞起来太麻烦了，是不是 vert.x 就是用 netty 实现了 http 协议了

@tairan2006 老哥我说过多线程方案性能肯定不行
200 qps 访问 5 个 api 不能开 1000 个线程吧，线程复用一个机器 8core 开 16 个工作线程的话，每次并发的请求后端 api 是 16，每个 api 平均耗时 10ms 的话，第 200 个请求得等到什么时候呢？量少了确实没什么问题，java 类似的工具包确实也多如牛毛

@guyeu 线程池在并发量大的情况下不如协成吧
感觉线程池的原理是使用多线程进行 http 请求，比如 5 个 api，开 5 线程，然后聚合，但是每个线程在执行的时候 io 是阻塞的，大部分的线程时间都浪费在阻塞上了，如果我们这种聚合 api 数据的请求特别多，比如 1000qps，复用五个线程或者多开点 20 个，相当于 1000 个要请求 5000 次后端 api，在线程池里排队处理的话太慢吧