2019-12-25“如果活跃粉丝数量超过了长度，就把最先加入的粉丝从列表里剔除”，这块是不是会有问题。
最先假如的活跃粉丝很可能一直是活跃的，因为长度有限的原因就把他挑出来会不会不太好。作者回复: 剔除了无非就是无法实时获取到消息，但是他还是会被加入到活跃粉丝列表中，而且，在刷新信息流的时候可以拉取大V的发件箱做数据补偿
3
2019-12-25老师有两个地方没懂希望能解答下
1.缓存副本 100m缓存了60% 使用了60m带宽 ,主缓存 消耗剩下40%就是40m带宽 这样的话 加起来不还是100m带宽吗
2.推拉模式的例子,只有活跃用户是实时推送,不活跃用户异步推送,这样的话不是都使用的推模式吗？作者回复: 1. 但是每一个缓存的带宽降低了
2. 不活跃用户是不推送，但是不活跃用户上线后会拉取发件箱，所以叫推拉结合 1 1
2019-12-25这两篇真的实践出真理，好厉害老师作者回复: 谢谢，我只是站在前人的肩膀上😂😂
1
2019-12-25这个专栏真的篇篇干货，每篇都能让我理通一些以前似懂非懂的疑惑，忍不住留言感恩一下作者回复: 谢谢，有帮助就好~
1
2020-02-03请问缓存中只放微博ID，实际内容还要去DB查吗？作者回复: 当然了~
2020-01-28春节把整个专栏理了一边，收获颇多，非常喜欢老师的实际案例的分享，结合理论，每篇都都值得细读借鉴。
后续希望有机会应用于实际工作！作者回复: 谢谢~
2020-01-13打卡。看了两篇，然后我真不知道网易还有微博::>_<::作者回复: 阵亡了有很多年了
2019-12-281.闲时非活跃列表的活跃用户的信息同步。这个感觉也可以有。一礼拜没登陆的用户可以跳过，这种用户登陆时拉能更好的优化数据传输。
2.分到6个缓存节点各自做批量拉取，能理解。但如果是redis集群，我是不是得再业务层再实现一套一样的分槽算法？作者回复: 差不多吧 需要知道在哪一个节点上
2019-12-27老师666作者回复: 谢谢关注，感谢一路相伴，祝君前程似锦
2019-12-27老师你好，查询后数据聚合的时候，分页怎么做的呢？
2019-12-26打个卡结束了，第二遍好好总结下作者回复: 感谢您的一路陪伴，㊗️前程似锦～
2019-12-26老师向你请教问题，开发的服务端程序与客户端通信现在连接有10个，接收发送socket，现在客户端发送了日志或报警信息都是毫秒级的2到3毫秒的日志和报警上来，中间还有业务交互现在能收的过来，处理上用队列，而且涉及业务的要马上响应超时时间2秒，消息日志报警业务都上来，怎么提高处理速度，业务上有顺序的，提高吞吐率作者回复: 说实话，我没看懂。。是说要传递日志和业务数据，然后要保证业务处理速度？
4