feed留,单聊群聊,系统通知,状态同步,到底是推还是拉?

  1. 云栖社区>
  2. 阿里云MVP>
  3. 博客>
  4. 正文

feed留,单聊群聊,系统通知,状态同步,到底是推还是拉?

初商 2019-08-09 23:47:30 浏览196

今天抛一个话题,根据业务现象,一起讨论其后端实现是推还是拉?

一、feed流

可以理解为一个发布订阅业务,典型业务是微博(朋友圈)。你关注了姚晨的微博,姚晨发布了消息,你的主页能看到她最新发布的消息,这个场景是推送,还是拉取呢?

画外音:微博是弱关系,关注无需对方同意,粉丝可以无上限;朋友圈是强关系,好友需要对方同意,好友个数有上线。

如果推送,姚晨发布消息的时候,要把消息ID投递到所有粉丝的主页消息队列里,推送量巨大。

如果拉取,一来主页消息无法实时更新,二来每次刷新动作非常复杂:

拉取你关注人的list

拉取这些人的消息list

对于这些人的这些消息进行rank处理,例如按照时间排序

还无法对主页进行缓存,因为只要有关注人发布消息,主页内容就会变化

还得考虑“不看谁的消息”,以及“消息不给谁看”

...

是不是觉得有点烦?如果你是架构师,你会怎么做?

二、聊天消息

聊天消息又分为单聊和群聊,典型的业务是微信。和朋友小窗沟通是单聊,群内扯淡是群聊。

单聊,很容易想到是服务器推送,但浏览器里的聊天工具JS只能使用http式的request - response协议,又能不能保证消息的实时性呢?

群聊,一个群500个人,有人在线,有人离线,到底是推送,还是拉取呢?

如果是推送,1条消息将转变为500条消息,系统压力会异常之大。

如果是拉取,消息的实时性又该如何保障呢?

还有一个坑爹的需求,“钉钉”的群聊天消息“已读回执”,这个需求简单描述是:对于每一条你发出的每一群消息,你能够看到,多少人已读,多少人未读。这个群消息已读回执,猜猜看,又是怎么实现的呢?

三、系统通知

系统消息听上去比较泛,典型的业务是QQ的登录广告弹窗,以及登录后的右下角广告提示。

  • QQ每天首次登录后的新闻弹窗

拉取?第二次登录却又没有。

  • QQ运行过程中的QQ弹窗广告

推送?一次推送几千万条,会不会系统抖动?

或许,真实的实现方式或许与我们想的并不一样。

四、状态同步

玩桌面QQ时,收到过“你的好友XXOO登录了”的弹窗提示么?这是一个好友登录/登出状态的客户端同步。同理,群有500人,每个群友的在线/不在线状态又是怎么实现同步的呢?

推送?那一个用户登录退出都要推送N个好友?M个群友?

拉取?如何保证好友状态,群友状态的实时性?

画外音:好友/群友状态一致性是非常复杂的,移动的时代,索性引入“一律在线”的概念,微信的好友就不存在所谓“头像亮”和“头像灰”的概念了,客户端状态同步这一块复杂性有所降低。

看到产品功能,思考后面的技术实现,其实是很有意思的一件事。

究竟是推,还是拉?大伙怎么看。

还有其他业务场景的疑惑,也欢迎评论提问,有价值的问题,5月份逐条解答。

画外音:自从有了群消息已读回执,我再也不能装作不在线,领导的消息没看到了。