@reus 刚试了下并不会这样，buf 给多大，就只读多大的，有多余的下次能读到。

为什么要解析了签呢，直接用 http body 签不就好了。

之前？

@king2014 虽然很吃 cpu 但是不妨碍上生产环境，无非就是堆机器了。 而且大部分项目并发都到不了 100。

@snail404
@king2014 我去年压过 laravel，开启 opcache，关闭 session debug 等。 就两行代码，sleep 50ms 模拟业务耗时，然后直接返回 4kb 数据。 100 并发 cpu 就爆了，4 核心的机器。。。

@gouchaoer redis + cron 算是很简单的了。使用队列也还不错，因为往往不只是一个简单的+1 的操作，虽然有 io，但也是为了访问数据库削峰。您说的 udp 还是不建议的，毕竟可靠性要比其他方案低，之前听人说 udp 本机丢包都不稀奇。apcu 这种假如有 10w 个文章，是需要 10w 个 key 来计数吗？ redis 的话用一个 hash 结构的 key 就够了，假如一篇文章被访问几次，然后长期不被访问，岂不是计数一直落不了库了，然后 fpm 重启这些计数都会丢失。

@lhx2008 感觉您说的不是重放，而是业务上的幂等。

@reus 这样的话好像得事先自己知道列表中那些变化了，才好写 shouldComponentUpdate，不然落到 elems 长度为 1 的时候再判断就还是全列表扫描了。

还有就是列表里面有 800 个变化了，这个方法貌似也不合适。可能是我哪里理解的有偏差。。。

@reus 大佬 我很少写前端，不过对你说的组织二叉树很感兴趣。假如把后端返回的列表数据用平衡二叉树来组织。那 react 的 render 函数可以有区别的搜索替换子组件吗？还是说就是在 render 里面简单的中序遍历二叉树呢？假如后端返回的 1000 行列表其中 800 行都变了呢？是不是组织二叉树结构也没啥优势了？

@echo1937 想知道用 centos 的人，有多少找过红帽培训，又有多少找过红帽来兜底呢？ 所以到底是为什么呢。。。

@pangliang tcp 的角度来看最小传输单位应该是字节吧，而不是“包”。tcp 两端，一端发的是字节流，另一端接的也是字节流。你说的这个 api，应该是我现在收到多少字节流 我就读多少字节没毛病啊。应该不是“块化”了。

我记得 php7 的 mongodb 扩展只支持长连接，没有短连接的配置。很无语。。。

php 本身就是模板引擎，用先进的模板引擎，感觉就是在模板引擎上又造一套模板语言。感觉把原生的 php 写工整点也还行吧，不过现在都是前后端分离比较多。