本文由淘宝音讯业务团队李历岷（花名骨来）原创分享，首次发表于公众号“淘系技术”，有订正和改变。
1、引言
本文来自淘宝音讯业务团队的技术实际分享，剖析了电商 IM 音讯平台在非传统 IM 利用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时音讯散发投递的一些架构方面的设计实际。
目前，阿里的 IM 音讯业务团队负责新批发畛域 IM 音讯平台的建设，通过 IM 即时通讯产品（push、聊天机器人、单聊、群聊、音讯号和聊天室）构建连贯消费者和商家的沟通和触达渠道，每天解决百亿级的生产规模，撑持了直播互动、客服服务、商家群经营、品牌资讯、营销推送等电商畛域 BC 互通的业务场景。
（本文同步公布于：http://www.52im.net/thread-3252-1-1.html）
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 的状况下，尽可能地防止单点瓶颈带来集群瓶颈乃至整体不可用。
“高可用架构“是技术人员永恒不变的主题之一，随着用户规模增长以及集中流量暴发的情景下，更须要敏锐地找到全链路单点问题，提前预判定义出面临的问题。而后给出正当的优化计划，最终灰度切流以及全链路压测验证保障整体计划有序推动，尤其面对的在线系统优化，好比开着飞机换轮胎一样。具备优化成果数据和监控是掂量每一步的预期收益，只有这样才能够做好“架构演进”，才能够继续交付更好的用户产品体验，博得用户的青睐，以及互动成果和产品流畅性才能够失去用户满意度晋升。架构演进是个动态化的过程，须要继续投入和改良，推动全链路整体落地。
附录：更多相干材料
[1] 无关阿里巴巴的文章分享：
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
《古代 IM 零碎中聊天音讯的同步和存储计划探讨》
《阿里技术分享：深度揭秘阿里数据库技术计划的 10 年变迁史》
《阿里技术分享：阿里自研金融级数据库 OceanBase 的艰苦成长之路》
《来自阿里 OpenIM：打造安全可靠即时通讯服务的技术实际分享》
《[钉钉——基于 IM 技术的新一代企业 OA 平台的技术挑战 (视频 +PPT) [附件下载]](http://www.52im.net/thread-52…》
《[阿里技术结晶：《阿里巴巴 Java 开发手册(规约)- 华山版》[附件下载]](http://www.52im.net/thread-14…》
《[重磅公布：《阿里巴巴 Android 开发手册(规约)》[附件下载]](http://www.52im.net/thread-14…》
《作者谈《阿里巴巴 Java 开发手册(规约)》背地的故事》
《《阿里巴巴 Android 开发手册(规约)》背地的故事》
《干了这碗鸡汤：从理发店小弟到阿里 P10 技术大牛》
《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》
《淘宝技术分享：手淘亿级挪动端接入层网关的技术演进之路》
《难得干货，揭秘支付宝的 2 维码扫码技术优化实际之路》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
《阿里技术分享：电商 IM 音讯平台，在群聊、直播场景下的技术实际》
[2] 无关 IM 架构设计的文章：
《浅谈 IM 零碎的架构设计》
《简述挪动端 IM 开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的挪动端 IM 架构设计实际分享(含具体图文)》
《一套原创分布式即时通讯(IM) 零碎实践架构计划》
《从零到卓越：京东客服即时通讯零碎的技术架构演进历程》
《蘑菇街即时通讯 /IM 服务器开发之架构抉择》
《腾讯 QQ1.4 亿在线用户的技术挑战和架构演进之路 PPT》
《微信后盾基于工夫序的海量数据冷热分级架构设计实际》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《疾速裂变：见证微信弱小后盾架构从 0 到 1 的演进历程（一）》
《17 年的实际：腾讯海量产品的技术方法论》
《挪动端 IM 中大规模群音讯的推送如何保障效率、实时性？》
《古代 IM 零碎中聊天音讯的同步和存储计划探讨》
《IM 开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM 开发基础知识补课(三)：疾速了解服务端数据库读写拆散原理及实际倡议》
《IM 开发基础知识补课(四)：正确理解 HTTP 短连贯中的 Cookie、Session 和 Token》
《WhatsApp 技术实际分享：32 人工程团队发明的技术神话》
《微信朋友圈千亿访问量背地的技术挑战和实际总结》
《王者光荣 2 亿用户量的背地：产品定位、技术架构、网络计划等》
《IM 零碎的 MQ 消息中间件选型：Kafka 还是 RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类利用场景为例，总结海量社交零碎的架构设计步骤》
《疾速了解高性能 HTTP 服务端的负载平衡技术原理》
《子弹短信光鲜的背地：网易云信首席架构师分享亿级 IM 平台的技术实际》
《知乎技术分享：从单机到 2000 万 QPS 并发的 Redis 高性能缓存实际之路》
《IM 开发基础知识补课(五)：通俗易懂，正确理解并用好 MQ 音讯队列》
《微信技术分享：微信的海量 IM 聊天音讯序列号生成实际（算法原理篇）》
《微信技术分享：微信的海量 IM 聊天音讯序列号生成实际（容灾计划篇）》
《新手入门：零根底了解大型分布式架构的演进历史、技术原理、最佳实际》
《一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际》
《阿里技术分享：深度揭秘阿里数据库技术计划的 10 年变迁史》
《阿里技术分享：阿里自研金融级数据库 OceanBase 的艰苦成长之路》
《社交软件红包技术解密(一)：全面解密 QQ 红包技术计划——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从 0 到 1 的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背地的技术细节》
《社交软件红包技术解密(四)：微信红包零碎是如何应答高并发的》
《社交软件红包技术解密(五)：微信红包零碎是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包零碎的存储层架构演进实际》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实际》
《社交软件红包技术解密(八)：全面解密微博红包技术计划》
《社交软件红包技术解密(九)：谈谈手 Q 红包的性能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手 Q 客户端针对 2020 年春节红包的技术实际》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《即时通讯新手入门：一文读懂什么是 Nginx？它是否实现 IM 的负载平衡？》
《即时通讯新手入门：疾速了解 RPC 技术——基本概念、原理和用处》
《多维度比照 5 款支流分布式 MQ 音讯队列，妈妈再也不放心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的 IM 零碎架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的 IM 客户端架构演进和实际总结》
《从游击队到正规军(三)：基于 Go 的马蜂窝旅游网分布式 IM 零碎技术实际》
《IM 开发基础知识补课(六)：数据库用 NoSQL 还是 SQL？读这篇就够了！》
《瓜子 IM 智能客服零碎的数据架构设计（整顿自现场演讲，有配套 PPT）》
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
《微信后盾基于工夫序的新一代海量数据存储架构的设计实际》
《IM 开发基础知识补课(九)：想开发 IM 集群？先搞懂什么是 RPC！》
《阿里技术分享：电商 IM 音讯平台，在群聊、直播场景下的技术实际》更多同类文章 ……
本文已同步公布于“即时通讯技术圈”公众号。
本文在公众号上的链接是：点此进入，原文链接是：http://www.52im.net/thread-3252-1-1.html