|
|
|
|
移动端
创建专栏

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

看到产品功能,思考后面的技术实现,其实是很有意思的一件事。今天抛一个话题,根据业务现象,一起讨论其后端实现是推还是拉?

作者:58沈剑|2018-05-06 16:08

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


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

一、feed流

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

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

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

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

  • 拉取你关注人的list
  • 拉取这些人的消息list
  • 对于这些人的这些消息进行rank处理,例如按照时间排序
  • 还无法对主页进行缓存,因为只要有关注人发布消息,主页内容就会变化
  • 还得考虑“不看谁的消息”,以及“消息不给谁看”
  • ...

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

二、聊天消息

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

  • 单聊,很容易想到是服务器推送,但浏览器里的聊天工具JS只能使用http式的request - response协议,又能不能保证消息的实时性呢?
  • 群聊,一个群500个人,有人在线,有人离线,到底是推送,还是拉取呢?

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

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

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

三、系统通知

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

  • QQ每天首次登录后的新闻弹窗:拉取?第二次登录却又没有。
  • QQ运行过程中的QQ弹窗广告:推送?一次推送几千万条,会不会系统抖动?

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

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

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

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

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

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

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

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

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

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 分层架构,前后端分离有啥坏处?
  2. 前端本地文件操作与上传
  3. 后端程序员都做些什么?
  4. 前端不止:请告诉我,你要什么样的图标
  5. Redis为什么这么快?一文深入了解Redis内存模型!
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多