深度剖析「圈组」消息系统设计 | 「圈组」技术系列文章
导读:
网易云信新晋的 IM 顶流产品「圈组」出道后获取到了极大的关注,很多云信的客户在接入的同时对于「圈组」的底层技术细节和原理也非常关注,为此,我们决定推出云信「圈组」相关的系列技术文章,分享网易云信在「圈组」技术设计上的一些思考。
文|曹佳俊 网易云信资深服务器开发工程师
一、技术选型
在介绍「圈组」的技术细节之前,我们先分析一下圈组的技术特点(了解「圈组」可阅读下面两篇文章:行业洞见丨Discord 狂奔的背后与网易云信「圈组」的长期主义 或 正式出「圈」丨网易云信圈组的近谋与远虑),「圈组」产品最大的特点是什么?首先是 server/channel 的二级结构;其次是构建在二级结构之上的大规模社群(单个 server 数十万甚至上百万成员),以及使用复杂的身份组系统来管理如此规模的社群组织和成员。
那么对于这样一个新颖的 IM 系统,在技术上应该如何实现呢?
一种简单的思路是改造已有的 IM 系统,对于「圈组」这样的类 Discord 社群,第一个思路是拓展我们的群组功能,猛一看在很多方面确实挺像的,我们做了个简单的对比:
从上面的表格可以看到,「圈组」和群组最大的不同,一个是容量的区别,一个是二级结构。其他的诸如身份组、个性化推送策略,似乎只要适配的做一下就可以了,那么是不是只要想办法提升一下群组的容量,再在业务层封装一下二级结构就可以了呢?答案显然是否定的,或者至少说基于群组去扩展不是一个很好的想法。
首先是二级结构,在类 Discord 的二级结构中,成员的管理在 server 层,而 channel 成员是继承自 server 的,而且在 channel 之上还有很多可见性的配置(云信「圈组」提供了黑白名单机制,Discord 则提供了查看频道权限),在这种机制之下,任何 server 层面的成员变动,都可能影响全部或者部分频道的成员列表;面对这种复杂的结构,群组有两种思路去实现,一种是 N 个群,逻辑上隶属于同一个 server;还有一种是一个群映射为一个 server。不管哪种方式,先不说消息投递这块的逻辑,仅成员管理上逻辑的耦合和交织的复杂性,足以劝退任何人。
其次是容量,常规的群组的容量一般只有数百,最多可以扩展到数千,对于群组成员的管理,我们一般采取全量+增量同步相结合的方案,客户端和服务器映射到相同的群组镜像(群信息+群成员等),此时很多操作,例如群成员的展示、检索,消息的艾特等,都可以基于纯客户端进行。而「圈组」要求几十万甚至上百万的容量,显然客户端无法一次性获取到所有成员,如果你一次性加入多个 server,那成员的数量将更加膨胀。因此在「圈组」这种大规模社群的设计中,很多逻辑都会转向云端,此时不管是 SDK 还是服务器,均需要修改原有的设计逻辑。
此外,大规模社群带来的是消息爆炸,在原有的群组设计中,假设一个人同时加入了 1000 个群,那么这 1000 个群内的所有消息均会在第一时间下发给给客户端,但是在一般的业务场景中,不会所有的群都同时活跃,假设这 1000 个群变成了 1000 个服务器/频道,作为一种社群组织,同时活跃的可能性将大大增加,而且每个服务器/频道的人数远远超过普通的群组,叠加之后带来的消息爆炸现象在原有的群组体系中将带来极大的压力,压力包括多方面:首先是海量消息的存储压力,其次是海量消息在线广播/离线消息推送带来的带宽和服务器压力,以及客户端在面对大量消息冲击时如何有效地接受和合理的展示。
除了容量和二级结构,包括身份组、成员管理、个性化推送策略等等,是否真的适合在群组中添加这些复杂逻辑呢,强行绑定在一起会不会既没有一个好用的类 Discord 平台,也使得原始的群组功能繁杂,反而降低了易用性呢?
经过上面的一些分析,我们基本可以得出一个结论,在已有的群组基础上扩展来实现一个类 Discord 功能的社群,显然不是一个很好的思路,那么还有其他“捷径”吗?聊天室也是一个潜在的选项,聊天室的一大特点就是支持超大规模同时在线(参考文章:网易实践|千万级在线直播弹幕方案),容量似乎已经不是问题,但是当考虑添加其他一些强社交关系的特性时(如成员、身份组等)就显得有点为难了,聊天室本身就是来去自如的一个开放空间,这个和圈组的产品本身定位互相冲突的,因此基于聊天室扩展的方案也基本 pass 掉了。
二、技术难点
基于上述种种的思考和讨论,最终网易云信选择脱离已有 IM 体系,从零研发一套全新的社群方案「圈组」,「圈组」不是一个简单的 IM 功能,而是一套可以独立运行的 IM 系统,经过上面的讨论,相信大家对「圈组」本身的技术特点和难点也有所理解,可以归纳为以下几点:
二级结构下成员无上限的社交关系系统设计。
超大社群下消息系统设计。
复杂高效的身份组系统设计。
三、「圈组」消息系统技术剖析
本文将针对上述三点之中的第二点:超大社群下的消息系统设计,分享我们的一些技术设计原理和经验。
(一) 「圈组」整体架构
上面展示了「圈组」服务整体的架构,可以看到整个「圈组」服务是一个分层的架构,首先是接入层,包括 LBS 服务和长链接服务器以及 API 网关,对应客户端 SDK 和用户服务器;后面是网络层,包括大网 WE-CAN 和协议路由服务;其次是服务层,划分了多个服务模块,每个模块都包括多个微服务;最后是基础设施。
(二)消息系统架构
这其中和消息系统相关联的包括接入层、网络层、以及后端的登录/订阅/消息/检索等模块,基本架构如下:
下文我们将对消息系统中各模块分别展开介绍。
(三)消息系统技术细节
消息系统中第一个要讨论的点就是消息的存储和分发方式,包括在线广播、离线推送、历史消息三个维度。
在线广播
对于一般的群组来说,在线广播的一般过程是这样的:依次查询群组里的所有人的在线状态,如果在线,则将消息发送给对应的长链接服务器。显然这种机制无法复制到「圈组」,因为在「圈组」的一个服务器里可能存在超过 100w 的人;此外,聊天室的广播模式也不能直接复用,因为在聊天室架构中,每个长链接映射到一个聊天室,因此当你登录到某个聊天室的时候,你只会收到该聊天室的消息,而对于「圈组」来说,每个用户会同时加入多个服务器/频道,而且会同时收到多个服务器/频道的消息。
针对「圈组」的上述特点,云信设计了消息订阅模式,也就是用户登录之后,需要订阅感兴趣的相关服务器/频道,服务器会记录下这个订阅信息,当有新消息的时候,服务器通过订阅关系(而不是在线状态)查询到需要广播的列表,通过这种方式就不再需要遍历服务器/频道里的所有用户;
但是当一个服务器/频道里在线人数非常多的时候,这个订阅关系仍然是巨大的,为此云信设计了一种两层订阅模型,所有的订阅关系会保存在长链接服务器上(QChatLink/QChatWebLink),同时长链接服务器会定时发送心跳给后端的订阅服务器,心跳信息相比原始的订阅信息会大大简化,比如长链接服务器上会记录账号 A 订阅了某个频道 A 的消息,如果有 1w 个账号,则有 1w 条订阅记录,而心跳信息里只会上报有 1w 个人订阅了某个频道 A 的消息,具体的账号列表则被精简掉了;当一条消息需要广播时,消息服务会访问订阅服务,获取到该服务器/频道被订阅的长链接服务器列表,并依次给该列表中的长链接服务器发送消息下发通知,长链接服务器收到通知后会根据订阅详情再广播给所有客户端。
此外,我们还提供了多种订阅类型,当你非常关心某个频道消息时(比如页面正停留在该频道),此时你可以订阅该频道的消息;对于其他频道,如果你仅仅需要知道该频道有多少条未读消息(或者有无未读消息),则可以选择订阅该频道的未读计数(或者未读状态),此时服务下发时仅会广播精简的消息体用于维护客户端未读计数,并且当未读计数达到一定阈值之后(比如 99+),服务器可以选择不再下发任何通知消息而不影响用户体验。
通过上文介绍的消息订阅模型,极大地提高了超大型的圈组频道/服务器消息在线广播的效率,降低了服务器压力;除此之外,我们还设计了针对小型频道的特殊策略,对于小型频道,即使不订阅,服务器也会下发消息通知给频道里所有人,从而减轻端侧消息订阅模型的维护成本;针对消息订阅机制本身,后续我们也会根据不同的业务场景,提供更多一站式的策略来帮助降低接入成本,提升整体的易用性。
离线推送
在强社交的场景下,离线推送对于维持用户粘性+提升产品体验有很大的作用。从技术角度看的话,主要解决2个问题,第一个是超大型服务器/频道的消息推送的效率问题;另外一个是提供足够丰富的推送策略来帮助 C 端用户,避免被过量的推送消息给打扰。
针对第一个问题,云信「圈组」针对不同规模的服务器/频道采取了不同的策略,对于小型频道,采用类似于群组的消息推送模型;而对于大型频道,对于每一条需要推送的消息,会根据目标用户的 ID 进行任务分片,多个节点并行操作,提高推送效率。此外分片会采用一致性策略,保证单个用户固定为某些节点,从而提高缓存命中效率。
针对第二个问题,云信「圈组」的推送策略可以用以下几句话来描述:
既关注促活,又保证不打扰
大型 server 是游乐场,只推送与用户相关的重要消息(如 @消息)
小型 server 是与朋友相处的小天地,支持消息的全部推送
并且未来用户还可以自定义消息的高低优先级,并搭配不同的推送配置(如不同的免打扰配置等):
历史消息
历史消息的存储在「圈组」的场景中也需要一些特别的设计。同样以群组为例,一般来说消息的存储方式有两种,写扩散和读扩散,在小型的群组或者多人会话中,写扩散模式可以简化设计,但是当群组规模扩大到一定程度(如万人群),读扩散就成了选择,而对于「圈组」这种单个服务器可能上百万人的“群组”中,除了常规的读扩散之外,我们还设计了多级缓存的结构来应对海量的读请求,基本的存储架构大致如下:
消息的存储主要包括两部分,一部分是消息本身,还有一部分是未读计数。
首先是写入,对于上述两者,我们都会使用中心化的缓存服务器来存储最近的数据,并使用异步+批量+聚合等手段,通过 MQ 异步落库,从而平衡写入效率(单条写入性能低)和写入读取延迟(异步写入有延迟)的问题,并且针对不同数据类型的特点,我们也选择了不同的存储方案(历史消息使用分布式时间序列数据库,未读计数使用分布式 k-v 数据库),最大化地提升消息存储和查询的性能和效率。
有写就有读,针对读取操作,所有最近的消息和未读计数均会存储在中心化缓存中,并通过先进先出和缓存过期等不同的策略来确保缓存中存储的永远是最新和最热的数据;此外对于消息 ID 和消息内容本身,中心化缓存中也会有不同的数据结构和过期策略,来平衡缓存命中率和缓存容量消耗;当缓存过期了,如果有关联的读写请求,将会触发缓存的重建,以保证缓存的命中率始终保持在较高水位;最后,当有高频的读请求,还会触发热点 cache 的检测,并将一部分读请求下沉到各个计算节点的内存中,以应对突发流量的冲击。
上述针对「圈组」的特别设计,消息存储系统可以应对几十数百人的小型圈组频道,也可以从容应对上百万的超大型频道。
特色功能
说完了消息系统的核心存储和分发模式,「圈组」的消息系统还提供了很多额外的特色功能:
消息更新:所谓的消息更新是指消息发送之后还允许修改,消息撤回和删除被认为是消息更新的一种特殊状态,这在管理一个大型社群中的消息时有着重要的作用。
消息互动(即将推出):「圈组」提供了比 Discord 的消息回复更强的 thread 聊天功能,不同于子区是单独开辟一块空间,thread 聊天可以让你在复杂的消息流中自动筛选出关于某一个话题的所有关联消息。「圈组」也提供了快捷评论的功能,你可以给一条消息添加各种自定义的表情,这在大型的频道中几乎是刚需,因为你再也不用忍受消息爆炸了。云信针对大型频道的快捷评论也做了特殊的优化,当一条消息获得大家的一致喜爱时,频道里所有人都可以给他点一个
深度剖析「圈组」消息系统设计 | 「圈组」技术系列文章相关推荐
- 深度剖析:Redis分布式锁到底安全吗?看完这篇文章彻底懂了!
阅读本文大约需要 20 分钟. 大家好,我是 Kaito. 这篇文章我想和你聊一聊,关于 Redis 分布式锁的「安全性」问题. Redis 分布式锁的话题,很多文章已经写烂了 ...
- 深度剖析:Redis 分布式锁到底安全吗?看完这篇文章彻底懂了!
作者 | Kaito 来源 | 水滴与银弹 阅读本文大约需要 20 分钟. 大家好,我是 Kaito. 这篇文章我想和你聊一聊,关于 Redis 分布式锁的「安全性」问题. Redis 分布式锁的话题 ...
- kafka基本操作:创建topic、生产/消费消息(同一消费组均分消息;不同消费组订阅消息)
创建topic topic01 一共3个分区 发送消息和接收消息 同一消费组内的消费者均分消息,但同一分区只能被同一消费组中的一个消费者消费: 不同消费组订阅同一主题,都会收到消息的. 验证 消息广播
- 构建万物可信互联的基石,带你深度剖析区块链跨链的关键技术,满满是干货!
[摘要] 什么是区块链,相信你一定有所了解,那么你是否了解区块链跨链技术呢?本文将从区块链跨链技术的起源发展.相关名词.关键技术和模型实现几个方面进行深度剖析,干货满满! 1.区块链跨链技术诞生背景及 ...
- 虚拟机无法接受组播消息_基于UDP的组播通信
基于UDP的组播通信 在Java实现基于UDP协议的发送端与接收端通信中,我们可以知道它的一些主要操作: 在发送端:1,创建绑定指定端口的发送接口:DatagramSocket(port) 2,创建绑 ...
- 高频通信电子线路—经典七管半导体超外差式调幅(AM)收音机(恒兴HX-6B)电路深度剖析介绍(上)
经典七管半导体超外差式调幅(AM)收音机(恒兴HX-6B)电路深度剖析介绍(上) 收音机虽然已经渐渐淡出人们的生活,但是其典型的电路常常会被作为高频通信电子线路.无线电通信或电磁场与电磁波等课程的案例 ...
- 正式出「圈」丨网易云信圈组的近谋与远虑
网易云信新晋的 IM 顶流产品「圈组」正式出道了. 「为融入圈子而欣喜,因倾注心血而热爱」,圈组的诞生旨在一站式帮助客户快速开发和构建强大稳定的即时通讯社群,让用户的欣喜和热爱在线上也能拥有一个承载之 ...
- 「深度剖析」程序员因为奇葩需求暴打pm,然后被双双开除
想必大家都听说了,这两天关于中国平安一个产品经理因奇葩需求和程序员爆发肢体冲突的事件在朋友圈被刷屏,更有现场打架视频在技术群里疯传. 在这里先带大家简单文字回顾下事情经过,N次打架视频和截图就不给大家 ...
- 微信回应「10 元就能在朋友圈改定位」;谷歌官方首次提及 Android 11;Node 8.16.2 发布 | 极客头条...
快来收听极客头条音频版吧,智能播报由标贝科技提供技术支持. 「CSDN 极客头条」,是从 CSDN 网站延伸至官方微信公众号的特别栏目,专注于一天业界事报道.风里雨里,我们将每天为朋友们,播报最新鲜有 ...
最新文章
- ksql 数量大于2_504深入解读路基土石方说明,路基填方数量组成?运距>15km咋办...
- [转载] iphone 很有意思的NSString 和 Autorelease
- MFC接收ShellExecute多个参数
- vlan之间互相访问_VLAN的划分和网络的配置实例
- c语言位操作大小写转换,C语言实现大小写转换的三种方法
- 漫画:什么是一致性哈希
- postgressql数据库给模式添加search_path
- es6 混合commjs_Webpack打包ES6和CommonJs混合React
- atitit opencv apiattilax总结 约500个函数 .xlsx
- jQuery中文文档(jQuery 3.1 参考手册+jQuery.api.3.2.1)
- 6.S081 Lab 1: Xv6 and Unix utilities
- 基于PHP的学生量化管理系统
- odoo:开源 ERP/CRM 入门与实践 -- 上海嘉冰信息技术公司提供咨询服务
- 【winui3】轻量笔记本应用
- Google Professional Data Engineer(PDE)考试
- 关于计算机的手抄报知识,电子手抄报
- 【新手引导】Image 的渗透事件
- vue v-for和v-if同时使用
- C++实现简单Kmeans聚类算法
- 武汉大学计算机学院编程能力,2014武汉大学计算机学院国家多媒体软件工程技术研究中心复试经验总结...
热门文章
- 有许多部分没有在cgroup中显示啊,current/high/low/min等等
- 一个测试员的工作与学习
- js函数中的参数的个数
- C++11之thread线程
- cocos2dx打飞机项目笔记五:CCSpriteBatchNode 的使用
- 如何正常使用Safari for Windows
- 光流 | 基于Matlab实现Lucas-Kanade方法:方法2(附源代码)
- SLAM | 三维重建方法之KinectFusion与ElasticFusion详解
- java 保留数字与中文_java 转中文数字
- bootstrap 右对齐样式_Bootstrap的文本处理
- 深度剖析:Redis分布式锁到底安全吗?看完这篇文章彻底懂了!