电商互动消息如何进行架构演进？，记一次字节跳动Java研发岗的面试经历

本文链接：https://blog.csdn.net/m0_60666452/article/details/137268774

优点：

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

缺点：

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

3、读写扩散混合模式

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

▐ 问题定义之直播互动消息

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

热点问题的产生需要从不确定性的流量来源说起。直播间人员规模天然和群聊不一样(单个群<=500人），一个直播间可以突破40万-200万之间设备同时在线，直播间在另一个层面是“特殊的群”，群维护了群和群成员强关系，直播间维护直播和设备之间的订阅弱关系，在扩散维度群按照500人进行分库分表切片模式分发下行消息，直播间需要以直播间几十万设备作为分段切片进行分发。同时直播间的指令消息如果不加以干预，会形成超大的流量热点和扩散问题，那么针对这个问题如何应对？

直播间互动全链路和核心处理节点

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

充分利用直播间在线人数

针对大直播间和小直播间区分对待，充分利用在线人数这个关键性指标，譬如小直播间不做buffer队列处理，所谓buffer，就是维护topic维度的缓冲队列，支持N秒或消息条数的异步flush机制，实现削峰过程，其中针对“可靠消息”进行持久化缓存存储，如果当前消息推送失败，重试3次或者下一条消息再次携带失败的可靠消息，整体按照推拉结合的方式，端侧做重复消息去重控制。

用户进出房间关系维护

从用户第一次进直播间，发起订阅请求，最终通过大小直播间分片进行路由到指定的直播间，针对特殊大直播间提前做好集群分片，或者通过每天的离线数据分析大直播间的账号，主播开播创建直播间的时候，提前做好分片确定性，在脉冲绑定关系的时候，流量分散到N台订阅集群进行绑定关系建立。

流控策略考虑

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

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

一致性Hash的架构必然存在热点问题，如果在直播间进行分散架构，必然存在指令风暴问题，基于此需要进行Hash热点二次打散处理，针对这样的热点问题技术上是可行的，热点问题散列到多台IP机器上进行流量承接，另外需要考虑直播间维度的统计数据分布式合并等问题，需要用到分布式锁并发写入统计数据，且直播维度数据合并计算，类似JDKStriped64原理。

对比两套架构思考

▐ 规模差异化架构思考

因为早期两套系统各自演进应对不同的流量和产品需求，用户规模化和产品要求带来的差异化架构，对比“群聊”和“直播间互动”两类互动场景，群聊基于消息、会话、会话视图以及附加消息存储和消息漫游能力进行整体设计，而对于直播间来说，围绕直播间大规模实时互动进行抽象设计，充分实现buffer/批量/订阅关系切片等机制。

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

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

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

▐ 不确定性流量的QoS思考

不确定性的流量如何转为确定性流量，是技术必须要解决的“确定性”问题。尤其面对流量需要确定性进行分解，分优先级保障不同的消息QoS能力是“高可用架构永恒不变”的主题，就像应用系统的限流，需要分场景进行流控一样。基于这样的思考推演，QoS分级机制来承诺消息服务SLA，最终才可以做到隔离/优先级/差异化处理，完成整体的消息顺滑体验。

小结

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

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

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

淘系技术部——消息业务团队

我们负责阿里新零售领域 IM 消息平台的建设，通过 IM即时通讯产品（push、聊天机器人、单聊、群聊、消息号和聊天室）构建连接消费者和商家的沟通和触达渠道，我们每天服务上亿消费者和数百万商家，处理百亿级的消费规模，支撑了直播互动、客服服务、商家群运营、品牌资讯、营销推送等电商领域 BC 互通的业务场景；同时，我们在消费者的购物体验上不断探索创新——直播、AR试用、游戏互动，为新的购物玩法提供灵活稳定的基础设施，实现阿里电商生态重要支点，为上百家APP 提供安全、稳定、标准化的电商组件SDK。不断提升消费这的体验和活跃，提升商家服务的效率和能力，促进商家业务增长。

**联系电话：18651806651

邮箱???：limin.llm@alibaba-inc.com

✿ 拓展阅读