共计 2462 个字符，预计需要花费 7 分钟才能阅读完成。
预约纸质版《作战地图》
5 月 26 日 -27 日，QCon 寰球软件开发大会落地广州。移步【融云寰球互联网通信云】回复【wicc】报名
融云 IM 服务架构师罗伟受邀分享“实时社区的海量音讯散发实际”，从实际中来的前沿技术分享，播种现场开发者的热烈响应和统一好评。
公众号后盾回复“QCon”获演讲 PPT~
大火的 Midjourney 与高度灵便的实时社区
实时社区的代表性平台 Discord 近期又播种了一波热度，这次是源于议论 AIGC 无奈绕开的“网红”Midjourney。
Midjourney 间接内置集成在 Discord 里，以频道的模式提供服务，上线不到一年曾经实现了近 1500 万用户和 1 亿美元营收。
这便是实时社区的神奇之处。它领有高度灵活性和可扩展性，能够适配多样玩法。无论是虚构团聚、游戏组队，还是 AIGC 新技术、新利用和新场景，都能够从频道中延展而出，缓缓积淀。
起初，Discord 被定义为 永远在线的聊天室，外面有各种简单的业务概念，比方子区、私有频道、公有频道。
但从产品状态来说，构建实时社区所应用的 融云超级群 产品，是齐全区别于聊天室和群聊的一种 IM 即时通讯会话类型。（👉点此理解 IM 产品全状态）
或者说，它能够被简略定义为 一般群与聊天室的汇合。
先说 成员关系：群组有下限，聊天室没有下限；实时社区像聊天室一样无成员下限，同时又像一般群一样，其成员关系是存储落地的，是永恒存在的。
再说 音讯可靠性：一般群离线再连时，服务端会把离线期间产生的音讯都同步到端上；聊天室用户个别只关怀实时音讯，且海量观众同时发同样的内容（如，赞、666），能够对音讯执行肯定抛弃策略。而实时社区是既有大量实时音讯，但同时又要保障可靠性，每条音讯都须要收到。
报名 WICC · 出海嘉年华
海量音讯高散发场景“避坑实录”
无成员下限且须要保障实时音讯可靠性，这就让高并发架构成为实时社区产品设计的要害。
简略来说，高并发架构就是要在正确响应业务申请的状况下，将时长及并发量的拐点后移。这对系统设计、代码都有极高要求，同时也是一个一直迭代、继续优化的过程。
融云高并发架构图，公众号后盾回复“QCon”看残缺 PPT
一个简单的业务零碎，必然须要一个足够简单的零碎来撑持，接入层、服务层、存储层都要别离做最优的思考和设计。
具体到融云超级群的实际计划上，以下是它的一个简化版本架构图，包含拜访接入、外部服务和数据存储及运行保护局部。
简化版融云超级群架构，移步公众号后盾回复“QCon”看残缺 PPT
在这里，Group 就是上行的主节点，次要负责信息的校验，比方群成员关系、禁言等，是咱们实现高可用的要害。
融云采纳弱状态服务实现高弹性伸缩，通过哈希算法，依据落点（如以用户 ID 为落点）将用户固定在一台机器上，让本地内存去缓存一些热点数据、音讯。过程中，须要解决以下问题。
1. 实时音讯如何解决？
在实时社区中，用户能够同时退出无数个“聊天室”，并且每个聊天室还有频道的概念，面临微小的音讯爆炸挑战。咱们通过 音讯驱动、增量拉取、订阅式会话驱动 的组合拳来解决这个问题。
音讯驱动 就是散发音讯的时候写入到内存音讯环，而非间接放到缓存中。而后通过内存里去读取，基于工夫戳告诉、拉取，基于用户落点读扩散，保障实时性。
增量拉取 就是为用户建设音讯索引，保障单个用户音讯工夫戳线性增长，保障音讯不丢。
订阅式会话驱动，不再基于音讯告诉，而是把会话的变更同步到客户端。客户端按订阅规定，拉取对应会话音讯。服务与客户端之间的网络交互，都被大大降低了，它们的时序也有了相应的保障。
图说实时音讯解法，后盾回复“QCon”看残缺 PPT
2. 海量离线音讯如何落地？
实时社区中的用户可能退出多个群，每个群又有海量音讯。用户离线再上线后，如果所有音讯都做同步，会是一个漫长的过程。咱们通过几个外围机制来解决这个问题。
会话驱动，用户离线期间产生的音讯由服务端计数，包含未读数、未读 @数、首条未读、最初一条音讯等。再次上线时，通过会话驱动间接一次同步至客户端，而不是一条一条拉取音讯，以解决海量离线音讯的高并发问题。
音讯断档，服务端基于拉取工夫戳判断，音讯环外的工夫戳则标记断档，音讯断档前的音讯，须要用历史音讯补全。这个机制次要解决会话驱动可能会产生的历史音讯不全问题。
历史音讯补全，不是服务端被动下发，而是由客户端依据最初一条音讯，向前补全，或者由客户端依据断档标记主动补全。
图说海量离线音讯落地，后盾回复“QCon”看残缺 PPT
音讯散发后的那些“后遗症”
假如一个有 80 万成员的实时社区，每秒公布 5 条音讯。在 10 台节点反对下，单节点可能解决 10 万用户。
那么，单节点须要每秒解决 40 万分发消息，也就是每秒须要 40 万次的内存计算更新。这将对 CPU 和网络造成微小压力。
图说实时音讯散发压力，移步公众号后盾回复“QCon”看残缺 PPT
融云在外部实际中把它做成了一个 实时会话，引入了读更新和写更新两个机制来实现流量削峰工作。
读更新，也就是说，不在散发的时候计算，而是在拉取的时候由服务端计算。因为在上行的时候曾经存储了会话的音讯索引，能够按用户所在的群和频道，依据会话的音讯索引计算未读数，也能够了解为是一个懒加载的模式。
理论业务中会有一些个人用户相干的个性，须要做到 写更新。比方，集体未读数变更时更新（@音讯），会话当日首条音讯时更新以及会话首次激活时更新。
图说散发压力化解，后盾回复“QCon”看残缺 PPT
这样，原来散发时须要做的 40 万次内存计算就间接被砍掉了，也就不会再耗费大量的 CPU 了。
与之对应的，用户上线时同步会话，主节点会在上行时保留一条占用存储十分小的音讯索引。
最终，就能够做到把顶峰流量计算和 CPU 占用转化为在用户拉取时才占用内存和网络，实现了削峰的目标。
作为国内第一款超级群 PaaS 产品和原生技术架构，融云超级群是专为 打造类 Discord 实时社区 而创立的全新会话类型。
这款产品目前曾经反对某大型游戏用户社区、某出海元宇宙社区、某会展元宇宙平台等多类业务上线并继续经营，在帮忙利用晋升用户粘性和拓展社交属性方面开释出了微小能量。
