@begeekmyfriend 而且，你的 node 对应了很多记录吧。理论上最优的话应该是操作某个记录就只给这个记录加锁。对整个 block 加锁会锁住很多无关的记录

@begeekmyfriend 你不是说只有 5 个 cache 吗，那就是对应 5 个锁了？我不清楚你的具体实现，你这样能做到 5 个以上的并发吗？

@begeekmyfriend 给 cache 加锁就是全局锁，插入、查询不应该使用全局锁

语言只是工具，用筷子吃饭和用叉子吃饭的区别。如果每次吃饭都需要别人告诉你这个东西能不能吃，那筷子用得再好也没用……

API 请求怎么可能知道屏幕参数……请求里面又没有这个东西。一般都是页面 js 统计发给后端的。
至于手机、PC、微信、APP 的判断只要在日志里记录 User-Agent 就行了

@enenaaa
什么需求一定要在一个 http 请求里完成？

一个请求 + 懒得编码 -> 同步等待
一个请求 + 异步 -> swoole
多个请求 -> 回调地址

原生的 php 不支持异步，你又嫌同步效率低，又要在一个 http 请求里完成，那就是无解...

校招就是有这样的风险，跳槽是人家的自由，只能怪贵司没留住人……

估计被封了网页微信的使用权限，无解……

websocket 也行，长轮询也行。并发是必然的，有多少用户在登录就会有多少并发。又想要实时又不要并发哪有这么好的事……

指定一个回调地址，当消息返回时调用该地址即可。
很多 web 端的异步处理，例如调用支付宝进行支付，都是这么做的。

@begeekmyfriend
-- B+tree setting...
Set data index file name (e.g. /tmp/data.index):
Set index file block size (bytes, power of 2, e.g. 4096): 4
config node order:1431655762 and leaf entries:1431655762
Please input command (Type 'h' for help): i 1
Segmentation fault (core dumped)

file: bplustree.c
line: 1079

_max_order = (block_size - sizeof(node)) / (sizeof(key_t) + sizeof(off_t));

有符号数与无符号数一起运算，导致 block_size < sizeof(node) 时返回非预期的结果

对于按时间订阅的服务，这么做没啥毛病

协议上只规定了两者有不同的用途，剩下都是客户端与服务端实现上的差别

想售后？先下载我们的售后 APP （#滑稽

@puritania 几千万粉丝其实数据量并不大。对于微博来说，上 TB 的内存集群都没啥问题吧。

@puritania 我不是说数据库特殊处理，我是说缓存特殊处理。
这种数据用 NoSQL 存储，根本没有分库分表的问题。用关系型数据库存储，必然达不到性能要求，必然要上缓存。数据库进行特殊处理，恐怕收益非常有限。

用户的关注关系是一个访问极端频繁的数据，是必然要缓存在内存里的。所以即使需要用关系型数据库做持久化，在设计上也不必太考虑性能的问题。
估计会针对大 V 和非活跃用户做一些特殊处理。