电商互动消息如何进行架构演进？

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

新的形势下，显著特点是时间跨度长、活动周期长以及用户互动玩法更多。从单用户CC分享到群内分享，以及直播间互动消息等，作为电商的消息IM承接着整个互动的场地，用户在整个“互动消息”场景下，可以进行实时分享、聊天、客服沟通、商家优惠、商家优惠活动和红包以及商品秒杀等。“消息”作为用户和用户之间架起“连接”的重要桥梁，消息连接了用户和用户、用户和商家、用户和平台等。

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

推荐阅读：读者对传统的IM系统架构有所了解

---

互动场景挑战

---

---

直播间：淘宝直播带来新的流量变化，百万在线已经成为常态化，大量的直播间7X24小时直播带货，用户在直播频道页频繁地进出不同的直播间，有时候被某个直播间吸引，停在那里等着优惠、红包和宝贝，随着主播在直播间喊一嗓子，推送一张宝贝卡片，几十万人蜂拥而至秒杀。这样的场景每天都在上演…

**互动PK群:**主互动玩法“超级星秀猫瓜分20亿红包”开启的时候，意味着大量互动拉赞、分享到好友、分享到群成为流量的入口，无论淘口令/图片等，大量的消息卡片被转发、二次转发带来的分享裂变效应，每天09:00和晚上22:00成为活跃的峰值，每个组队的用户拉群互赞，这样的场景从10月20日到11月11日持续每天固定时段上演…

**不确定性流量：**分享面板入口一次列表排布改变，营销活动的一次优惠推送，直播频道页一次运营活动都可能导致直播间/群的流量瞬间波动，纷涌而至的用户带来了大量的互动行为，各种点击/分享/消息发送纷至沓来，如何应对这样的流量和规模，作为平台系统，必须能够做到应对不确定性流量能力和机制，必须从流量入口到流量出口端到端考虑整体的全链路架构，是否存在单点瓶颈和缺口，尤其在大促前期，系统架构梳理、强弱依赖梳理、上下游链路串联、破坏性压测、脉冲流量压测和全链路压测保障和优化，以及配合相关的流量控制、预案保护、业务流量隔离机制、资源调控等手段，才得以做到“不确定性流量”向“确定性流量”转变，才可以更大程度上保障系统高可用和极致用户体验。

▐  问题定义之群聊

随着2018年淘系电商首推“双11合伙人计划”，更简单直接的双11玩法，给大众带来更多期待和惊喜。尤其是盖楼互赞活动更是把“群聊”推上风口浪尖, 在手淘APP内部分享比在微信和钉钉等社交/企业软件分享更加便捷和高效, 用户不停地在群内互动分享拉赞,通过好友助力提升盖楼积分。

基于传统的IM架构技术，尤其在群内聊天或者分享，每条消息按照群内人数进行写扩散，按照主互动500人群规模来计算，平均群大小320+，1:N的写入必然导致写入DB的RT以及存储压力，按照DB库承接120w/s写入速度，导致消息上行3K/s的极限，而实际参与互动分享的用户在峰值的时候远大于这部分互动分享和聊天消息流量，其次集群的写入不可能完全给IM聊天消息，还有其它的营销活动、交易、物流等通知类型的消息。基于“写扩散”架构，在高并发互动场景下遇到了瓶颈，导致消息大量的延迟下推，影响最终用户体验。

**基于写扩散的扩散比1:N，能否做到1:1写入？**答案是肯定，针对群内的消息可以分为“非个性化消息”和“个性化消息”，所谓“非个性化消息”就是大家看到都是一样的，应该只需要写一条数据，群内成员可以共享取这条数据，所谓“个性化消息”，指定某个成员发送的单边消息，譬如进群欢迎语等。

在群内，99.99%都是“非个性化消息”，也就是可以从1:N压缩到1:1写入，基于这个理论假设，需要考虑“读扩散”让每个用户的消息从对应的“群会话消息队列同步“数据，而不是从”用户队列同步“数据，其中同步队列围绕队列offset偏移量进行，通过队列的自增syncId保证有序，每个客户端维护相应的队列的同步位点，采取“客户端存储位点的去中心化“方案，实现”下行消息的推拉“结合，通过队列位点syncId进行比对，如果服务端消息队列syncId-客户端队列syncId=1，表示云端消息无空洞，否则携带客户端的队列和对应的syncId到云端重新同步区间数据，实现最终一致性。

**业界IM：**腾讯QQ、腾讯微信、网易云通讯、抖音IM、钉钉IM、脉脉IM、支付宝IM

**备注：**市面上APP80%都具备IM聊天能力，均采取写扩散简单模式进行云端消息同步

读写扩散技术方案对比

1、写扩散技术

优点：

• 整体架构简洁，方案简单，维护用户同步队列实现数据同步机制

• 无论是单聊还是群聊等会话消息，写入用户维度同步队列，集中获取同步数据

• 推和拉情况下，存储模型和数据处理简单，且天然支持个性化数据

缺点：

• 群会话消息，天然存在1:N写入扩散比，存储压力N倍压力，在线用户收到消息延迟增大

• 多个群内消息队列混合在同步队列，无优先级处理能力，无法针对互动群等做隔离

2、读扩散技术

优点：

• 降低写扩散N倍的DB存储压力，减少下行在线用户端到端扩散的RT时间

• 提升消息上行集群整体的吞吐量，用户体验更流畅

• 端到端实现会话级别的同步优先级队列，实现差异化服务

缺点：

• 整体架构偏复杂，需要维护每个动态会话消息同步队列，端侧需要实时感知新增的动态同步队列

• 客户端冷启动需要分散读取多个会话消息同步队列数据，对于存储会带来读QPS压力

3、读写扩散混合模式

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

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

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

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

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

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

充分利用直播间在线人数

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

用户进出房间关系维护

最后

最后，强调几点：

• 1. 一定要谨慎对待写在简历上的东西，一定要对简历上的东西非常熟悉。因为一般情况下，面试官都是会根据你的简历来问的； 能有一个上得了台面的项目也非常重要，这很可能是面试官会大量发问的地方，所以在面试之前好好回顾一下自己所做的项目；
• 2. 和面试官聊基础知识比如设计模式的使用、多线程的使用等等，可以结合具体的项目场景或者是自己在平时是如何使用的；
• 3. 注意自己开源的Github项目，面试官可能会挖你的Github项目提问；

我个人觉得面试也像是一场全新的征程，失败和胜利都是平常之事。所以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！

以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。

面试答案

以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！

以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。

面试答案

[外链图片转存中…(img-RRGtwRkG-1714762415250)]

[外链图片转存中…(img-mQYV5Ob9-1714762415251)]

[外链图片转存中…(img-y8SyhZ35-1714762415252)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录