乐趣区

关于社区:Qcon-广州主题演讲融云实时社区的海量消息分发实践

预约纸质版《作战地图》

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 实时社区 而创立的全新会话类型。

这款产品目前曾经反对某大型游戏用户社区、某出海元宇宙社区、某会展元宇宙平台等多类业务上线并继续经营,在帮忙利用晋升用户粘性和拓展社交属性方面开释出了微小能量。

退出移动版