2024年最全电商互动消息如何进行架构演进？，Java高级工程师必备知识

最新推荐文章于 2024-10-04 15:42:01 发布

2301_79098686

最新推荐文章于 2024-10-04 15:42:01 发布

阅读量809

点赞数 15

分类专栏：程序员文章标签：架构 java 开发语言

本文链接：https://blog.csdn.net/2301_79098686/article/details/138554591

版权

程序员专栏收录该内容

202 篇文章 0 订阅

订阅专栏

最后

很多程序员，整天沉浸在业务代码的 CRUD 中，业务中没有大量数据做并发，缺少实战经验，对并发仅仅停留在了解，做不到精通，所以总是与大厂擦肩而过。

我把私藏的这套并发体系的笔记和思维脑图分享出来，理论知识与项目实战的结合，我觉得只要你肯花时间用心学完这些，一定可以快速掌握并发编程。

不管是查缺补漏还是深度学习都能有非常不错的成效，需要的话记得帮忙点个赞支持一下

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

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

需要这份系统化的资料的朋友，可以点击这里获取

推荐阅读：读者对传统的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次或者下一条消息再次携带失败的可靠消息，整体按照推拉结合的方式，端侧做重复消息去重控制。