今天抛一个话题，根据业务现象，一起讨论其后端实现是推还是拉？
一、feed流
可以理解为一个发布订阅业务，典型业务是微博（朋友圈）。你关注了姚晨的微博，姚晨发布了消息，你的主页能看到她最新发布的消息，这个场景是推送，还是拉取呢？
画外音：微博是弱关系，关注无需对方同意，粉丝可以无上限；朋友圈是强关系，好友需要对方同意，好友个数有上线。
如果推送，姚晨发布消息的时候，要把消息ID投递到所有粉丝的主页消息队列里，推送量巨大。
如果拉取，一来主页消息无法实时更新，二来每次刷新动作非常复杂：
拉取你关注人的list
拉取这些人的消息list
对于这些人的这些消息进行rank处理，例如按照时间排序
还无法对主页进行缓存，因为只要有关注人发布消息，主页内容就会变化
还得考虑“不看谁的消息”，以及“消息不给谁看”
...
是不是觉得有点烦？如果你是架构师，你会怎么做？
二、聊天消息
聊天消息又分为单聊和群聊，典型的业务是微信。和朋友小窗沟通是单聊，群内扯淡是群聊。
单聊，很容易想到是服务器推送，但浏览器里的聊天工具JS只能使用http式的request - response协议，又能不能保证消息的实时性呢？
群聊，一个群500个人，有人在线，有人离线，到底是推送，还是拉取呢？
如果是推送，1条消息将转变为500条消息，系统压力会异常之大。
如果是拉取，消息的实时性又该如何保障呢？
还有一个坑爹的需求，“钉钉”的群聊天消息“已读回执”，这个需求简单描述是：对于每一条你发出的每一群消息，你能够看到，多少人已读，多少人未读。这个群消息已读回执，猜猜看，又是怎么实现的呢？
三、系统通知
系统消息听上去比较泛，典型的业务是QQ的登录广告弹窗，以及登录后的右下角广告提示。
- QQ每天首次登录后的新闻弹窗
拉取？第二次登录却又没有。
- QQ运行过程中的QQ弹窗广告
推送？一次推送几千万条，会不会系统抖动？
或许，真实的实现方式或许与我们想的并不一样。
四、状态同步
玩桌面QQ时，收到过“你的好友XXOO登录了”的弹窗提示么？这是一个好友登录/登出状态的客户端同步。同理，群有500人，每个群友的在线/不在线状态又是怎么实现同步的呢？
推送？那一个用户登录退出都要推送N个好友？M个群友？
拉取？如何保证好友状态，群友状态的实时性？
画外音：好友/群友状态一致性是非常复杂的，移动的时代，索性引入“一律在线”的概念，微信的好友就不存在所谓“头像亮”和“头像灰”的概念了，客户端状态同步这一块复杂性有所降低。
看到产品功能，思考后面的技术实现，其实是很有意思的一件事。
究竟是推，还是拉？大伙怎么看。
还有其他业务场景的疑惑，也欢迎评论提问，有价值的问题，5月份逐条解答。
画外音：自从有了群消息已读回执，我再也不能装作不在线，领导的消息没看到了。
