直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践

JackJiang · 3 年前

本文由淘宝消息业务团队李历岷（花名骨来）原创分享，首次发表于公众号“淘系技术”，即时通讯网收录整理时有修订和改动。

1、引言

本文来自淘宝消息业务团队的技术实践分享，分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。

目前，阿里的IM消息业务团队负责新零售领域 IM 消息平台的建设，通过 IM即时通讯产品（push、聊天机器人、单聊、群聊、消息号和聊天室）构建连接消费者和商家的沟通和触达渠道，每天处理百亿级的消费规模，支撑了直播互动、客服服务、商家群运营、品牌资讯、营销推送等电商领域 BC 互通的业务场景。

本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

本文是系列文章中的第2篇：

2、技术背景

2020年双11，第一次改变节奏，从光棍节变成双节棍，从一个峰变成了两个峰，在新的挑战下，如何做好技术保障，做好技术支撑，所有技术人都进入了一个新的学习过程。

新的形势下，显著特点是时间跨度长、活动周期长以及用户互动玩法更多。从单用户CC分享到群内分享，以及直播间互动消息等，作为电商的IM消息平台，承接着整个互动的场地。

用户在整个“互动消息”场景下，可以进行实时分享、聊天、客服沟通、商家优惠、商家优惠活动和红包以及商品秒杀等。

“消息”作为用户和用户之间架起“连接”的重要桥梁，消息连接了用户和用户、用户和商家、用户和平台等。

如何做到高并发强互动下消息有序地呈现在用户面前，是消息团队亘古不变的主题，尤其是在用户的互动行为不确定性情况下，在面对不确定性的流量和规模时，系统应该怎样做到“丝般顺滑”的体验呢？本文将带着读者一起来进行深入探讨。

3、强互动消息场景的技术挑战

不同于传统社区IM消息平台，电商IM消息平台有自已的互动场景特点。

3.1直播间

淘宝直播带来新的流量变化，百万在线已经成为常态化，大量的直播间7X24小时直播带货，用户在直播频道页频繁地进出不同的直播间。

有时候被某个直播间吸引，停在那里等着优惠、红包和宝贝，随着主播在直播间喊一嗓子，推送一张宝贝卡片，几十万人蜂拥而至秒杀。这样的场景每天都在上演 ...

3.2互动PK群

主互动玩法“超级星秀猫瓜分20亿红包”开启的时候，意味着大量互动拉赞、分享到好友、分享到群成为流量的入口，无论淘口令/图片等。

大量的消息卡片被转发、二次转发带来的分享裂变效应，每天09:00和晚上22:00成为活跃的峰值，每个组队的用户拉群互赞，这样的场景从10月20日到11月11日持续每天固定时段上演 ...

3.3不确定性流量

分享面板入口一次列表排布改变，营销活动的一次优惠推送，直播频道页一次运营活动都可能导致直播间/群的流量瞬间波动。

纷涌而至的用户带来了大量的互动行为，各种点击/分享/消息发送纷至沓来。

如何应对这样的流量和规模，作为平台系统，必须能够做到应对不确定性流量能力和机制，必须从流量入口到流量出口端到端考虑整体的全链路架构，是否存在单点瓶颈和缺口。

尤其在大促前期，系统架构梳理、强弱依赖梳理、上下游链路串联、破坏性压测、脉冲流量压测和全链路压测保障和优化，以及配合相关的流量控制、预案保护、业务流量隔离机制、资源调控等手段，才得以做到“不确定性流量”向“确定性流量”转变，才可以更大程度上保障系统高可用和极致用户体验。

4、强互动群聊中的消息架构实践

4.1传统IM中“写扩散”架构的瓶颈

随着2018年淘系电商首推“双11合伙人计划”，更简单直接的双11玩法，给大众带来更多期待和惊喜。

尤其是盖楼互赞活动更是把“群聊”推上风口浪尖, 在手淘APP内部分享比在微信和钉钉等社交/企业软件分享更加便捷和高效，用户不停地在群内互动分享拉赞、通过好友助力提升盖楼积分。

基于传统的IM架构技术，尤其在群内聊天或者分享，每条消息按照群内人数进行写扩散，按照主互动500人群规模来计算，平均群大小320+，1:N的写入必然导致写入DB的RT以及存储压力，按照DB库承接120w/s写入速度，导致消息上行3K/s的极限，而实际参与互动分享的用户在峰值的时候远大于这部分互动分享和聊天消息流量。

其次集群的写入不可能完全给IM聊天消息，还有其它的营销活动、交易、物流等通知类型的消息。

基于传统IM的“写扩散”架构，在高并发、强互动场景下遇到了瓶颈，导致消息大量的延迟下推，影响最终用户体验。

4.2“读扩散”架构的应用

基于写扩散架构的消息扩散比是1:N，那能否做到消息扩散比是1:1呢？

答案是肯定的：针对群内的消息可以分为“非个性化消息”和“个性化消息”，所谓“非个性化消息”就是大家看到都是一样的，应该只需要写一条数据，群内成员可以共享取这条数据（所谓“个性化消息”，指定某个成员发送的单边消息，譬如进群欢迎语等）。

在群内，99.99%都是“非个性化消息”，也就是可以从1:N压缩到1:1写入。

基于这个理论假设，需要考虑“读扩散”让每个用户的消息从对应的“群会话消息队列同步“数据，而不是从”用户队列同步“数据。

其中同步队列围绕队列offset偏移量进行，通过队列的自增syncId保证有序，每个客户端维护相应的队列的同步位点，采取“客户端存储位点的去中心化“方案，实现”下行消息的推拉“结合。

通过队列位点syncId进行比对，如果服务端消息队列syncId-客户端队列syncId=1，表示云端消息无空洞，否则携带客户端的队列和对应的syncId到云端重新同步区间数据，实现最终一致性。

传统的IM产品：腾讯QQ、腾讯微信、网易云通讯、抖音IM、钉钉IM、脉脉IM、支付宝IM。
PS：市面上APP80%都具备IM聊天能力，均采取写扩散简单模式进行云端消息同步。

4.3“读扩散”、“写扩散”技术方案对比

4.3.1）写扩散技术：

优点：

1）整体架构简洁，方案简单，维护用户同步队列实现数据同步机制；
2）无论是单聊还是群聊等会话消息，写入用户维度同步队列，集中获取同步数据；
3）推和拉情况下，存储模型和数据处理简单，且天然支持个性化数据。

缺点：

1）群会话消息，天然存在1:N写入扩散比，存储压力N倍压力，在线用户收到消息延迟增大；
2）多个群内消息队列混合在同步队列，无优先级处理能力，无法针对互动群等做隔离。

4.3.2）读扩散技术：

优点：

1）降低写扩散N倍的DB存储压力，减少下行在线用户端到端扩散的RT时间；
2）提升消息上行集群整体的吞吐量，用户体验更流畅；
3）端到端实现会话级别的同步优先级队列，实现差异化服务。

缺点：

1）整体架构偏复杂，需要维护每个动态会话消息同步队列，端侧需要实时感知新增的动态同步队列；
2）客户端冷启动需要分散读取多个会话消息同步队列数据，对于存储会带来读QPS压力。

4.4读写扩散混合模式

核心在于架构的演进推进“读写扩散混合模式“落地，结合两者的优点进行云端一体化数据同步技术，覆盖几千万互动群用户，保证整体峰值上行消息以及用户在群内端到端延迟体验，做到一条上行消息500ms以内到达群内其他用户端侧，让整体用户体验提升明显，群内强互动成为可能。

5、电商直播互动中的消息架构实践

5.1技术挑战

电商直播呈现大直播若干个（大于30W同时在线）、中直播间几百个、小直播几万个这样分布，尤其是晚会和主播带来的热点直播间效应，对系统整体的IM消息架构存在热点带来严重挑战。

热点问题的产生需要从不确定性的流量来源说起。

直播间人员规模天然和群聊不一样（单个群<=500人），一个直播间可以突破40万-200万之间设备同时在线。

直播间在另一个层面是“特殊的群”，群维护了群和群成员强关系，直播间维护直播和设备之间的订阅弱关系，在扩散维度群按照500人进行分库分表切片模式分发下行消息，直播间需要以直播间几十万设备作为分段切片进行分发。同时直播间的指令消息如果不加以干预，会形成超大的流量热点和扩散问题。那么针对这个问题如何应对？

直播间互动全链路和核心处理节点简易时序图如下：

即：观众互动消息 -> 网关接入 -> 应用系统Buffer(秒级直播间维度消息) -> 编码、合并、批量消息流 -> 直播间维度设备扩散 -> 设备长连通道推送 -> 设备接收 -> 解码消息 -> 业务处理。

5.2应对手段

5.2.1）充分利用直播间在线人数：

针对大直播间和小直播间区分对待，充分利用在线人数这个关键性指标。

譬如小直播间不做buffer队列处理（所谓buffer，就是维护topic维度的缓冲队列），支持N秒或消息条数的异步flush机制，实现削峰过程。

其中针对“可靠消息”进行持久化缓存存储，如果当前消息推送失败，重试3次或者下一条消息再次携带失败的可靠消息，整体按照推拉结合的方式，端侧做重复消息去重控制。

5.2.2）用户进出房间关系维护：

从用户第一次进直播间，发起订阅请求，最终通过大小直播间分片进行路由到指定的直播间，针对特殊大直播间提前做好集群分片。

或者通过每天的离线数据分析大直播间的账号，主播开播创建直播间的时候，提前做好分片确定性，在脉冲绑定关系的时候，流量分散到N台订阅集群进行绑定关系建立。

5.2.3）流控策略考虑：

流控不等于一刀切，而是针对不同的subType指令进行控制。

针对可靠消息（红包、优惠、宝贝卡片）等进行持久化存储，利用多次消息下推携带机制，同时兼顾端侧拉取机制，保证消息最终一致性且在3秒以内到达端侧。

5.2.4）一致性hash问题-热点直播间：

一致性Hash的架构必然存在热点问题，如果在直播间进行分散架构，必然存在指令风暴问题。基于此，需要进行Hash热点二次打散处理。

针对这样的热点问题技术上是可行的，热点问题散列到多台IP机器上进行流量承接，另外需要考虑直播间维度的统计数据分布式合并等问题，需要用到分布式锁并发写入统计数据，且直播维度数据合并计算，类似JDKStriped64原理。

6、“群聊”和“直播互动”的消息架构差异思考

因为早期两套系统各自演进应对不同的流量和产品需求，用户规模化和产品要求带来的差异化架构。

对比“群聊”和“直播间互动”两类互动场景，群聊基于消息、会话、会话视图以及附加消息存储和消息漫游能力进行整体设计。而对于直播间来说，围绕直播间大规模实时互动进行抽象设计，充分实现buffer/批量/订阅关系切片等机制。

对于关系来说：群关系是强关系，需要用户确认加群，才可以进群、退群、查看群好友等。对于直播间来说是弱关系，用户进直播、退出直播都是自动完成关系建立和取消，当然用户可以后续进入回放直播间。

因此：在功能上和模型设计上需要进一步思考，尤其现有回放直播间需要一套录制/回放指令机制，保存互动指令等关键性指令数据，而这点在消息IM场景完全支持了，包括用户可以漫游历史消息等。

技术的发展不会一尘不变，针对合适的场景进行差异化架构和设计才是最重要的，同样在应对不确定性流量这个场景下，解决问题的方式是不完全相同的，这个过程需要反复迭代和优化，围绕端到端用户体验这个核心目标进行技术演进才是最重要的价值选择和方向判断。

7、不确定性流量的消息QoS思考

不确定性的流量如何转为确定性流量，是技术必须要解决的“确定性”问题。

尤其面对流量需要确定性进行分解，分优先级保障不同的消息QoS能力是“高可用架构”永恒不变的主题，就像应用系统的限流，需要分场景进行流控一样。

基于这样的思考推演，QoS分级机制来承诺消息服务SLA，最终才可以做到隔离/优先级/差异化处理，完成整体的消息顺滑体验。

8、写在最后

面对不确定性的流量，需要进行流量再细分以及面向不同的场景采取不同的处理方案去应对，惯用的手段是指令合并处理、链路隔离和共享、租户存储隔离、流量打标机制区分场景来源等，以及有相对确定性的流量大脑进行观测，在峰值流量来临之前，需要具备流量感知和预警机制，做好流量的优先级划分，应急预案是快速失败限流还是慢速等待消费以及优先级控制等机制。

同时在系统层面，需要做到水平扩展能力，也就是能否通过弹性扩容的方式应对高流量的峰值，另外需要做到整体全链路合理的架构设计，避免“写入放大”以及“读取放大”的单点问题产生，需要针对入口流量和出口流量进行比对，是否可以做到上下游1:1的情况下，尽可能地避免单点瓶颈带来集群瓶颈乃至整体不可用。

“高可用架构“是技术人员永恒不变的主题之一，随着用户规模增长以及集中流量爆发的情形下，更需要敏锐地找到全链路单点问题，提前预判定义出面临的问题。然后给出合理的优化方案，最终灰度切流以及全链路压测验证保证整体方案有序推进，尤其面对的在线系统优化，好比开着飞机换轮胎一样。具备优化效果数据和监控是衡量每一步的预期收益，只有这样才可以做好“架构演进”，才可以持续交付更好的用户产品体验，赢得用户的喜爱，以及互动效果和产品流畅性才可以得到用户满意度提升。架构演进是个动态化的过程，需要持续投入和改进，推动全链路整体落地。

附录：更多相关资料

2 楼: wyshyg · 3 年前

看起来很不错

神秘人 *发表于 2 年前* · 发表于 2 年前

4 楼: 燕小六666 · 2 年前

文章很不错

5 楼: 登至必极 · 2 年前

文章很有深度，看了半天才看懂

6 楼: 正平_Mf8uk · 2 年前

推拉结合讲解的不错

7 楼: 正平_Mf8uk · 2 年前

activesync协议

8 楼: lancelot · 2 年前

可以

9 楼: lancelot · 2 年前

不错

10 楼: 卷王 · 1 年前

学习了

11 楼: 天问 · 1 年前

消息优先级如果是kafka的话，是不是可以重新建一个topic来实现

12 楼: Frank · 6 个月前

人狠话不多,直接上图

本文目录

1、引言

2、技术背景