@littlemcdull 是的是这款！

像上面 @hahasong 说的，先界面 UI 实时响应，然后前端 /客户端先把用户点赞过的内容先缓存起来，后端用队列来将点赞数据落地到 DB 。请求用户点赞状态 /计数的时候，返回结果带上一个版本号，前端通过版本号来对比来决定是否+1 或者替换掉服务端的数据，这样是否可以？

点赞这种东西，不需要强一致性的，只需要保持最终一致就好了。至于数据丢失，肯定会有的，CAP 理论，看你们怎么取舍而已。保证 BASE 可用就好了。个人理解，欢迎友好交流~

我感觉有点像 redis 的 pipeline 模式，管道式执行请求逻辑，一定程度上减少了接口的请求量，还能臆想到的就是能根据 command 来判断哪些 command 是可以异步 /并发执行的，哪些需要同步执行

总结一下：
1:分组看见的情况，你分组时候只有组内这些人可见。无论你后来怎么折腾都是这些人可见。
2:分组不可见的情况，当你指定某组内成员不可见时，这些人是不可见的。无论你后来怎么折腾，也只有当前这些不可见的人不可见。

@996icu007007 跟这个没关系吧，不要乱猜

@wingoo 我想问的就是技术方案

@aqqwiyth 你想的太简单了，他告诉你从微信抄，但是微信服务端怎么实现的这个功能你是不知道的...

@james2013 尝试过，并没有什么有效的信息

@gxw86 你别说，群里面真有人建议我这么做

@IVeverKB 是啊，不然为什么叫停更了呢？

@MakHoCheung 但是微信读书的体验实在是没那么好

@toeii 估计也不会回复了

@frandy 这个也不错的样子，感谢

@ledkk 唉，希望你以后不会再有这样的境遇了~

@ledkk 最后怎么收场？什么结果了？

@MJZ1995 唉，我也不知道能怎么提高一点速度。。。

@sphawkcn 好的，感谢指点

@Ziya 大家都能指出这个问题，所以后面能怎么挽回一下吗？

@danhahaha 我也熬了不少夜，我的尿性有时候自己看了都觉得难顶，罪过