1

随着移动互联网的发展,即时通讯服务被广泛应用到各个行业,客户业务快速发展,传统百人或千人上限的群聊已经无法满足很多业务发展需求,因此网易云信IM专属云推出万人群服务。

本篇文章主要介绍网易云信IM万人群的设计方案。

万人群场景需要解决以下问题:

消息需要按1:9999的比例进行转发投递,按常规消息处理流程将产生大量的子任务,对系统吞吐量的要求极高;
在微服务系统架构下,如果不采用一些优化方案,服务以及存储(DB、缓存等)之间的QPS和网络流量将非常高;
以群为单位的缓存(如群成员列表)内存存储开销较大(假设一个成员200Byte,万人群约2MB);
群成员登录后需要同步群离线消息,智能手机上App前后台切换产生的较多登录同步消息协议,因此需要优化消息同步方案。
为了解决以上问题,万人群技术方案采用了“聚合+分层/组+增量”的设计思路:

图片描述
一、万人群消息处理流程
1、 按群维护在线群成员信息,主要包含两部分(可以理解为两个缓存集合)

a) 群成员在线信息:即用户在线状态变化(上线、下线)时,更新相应群的在线状态信息(即动态维护群有哪些成员在线);

b) 成员IM长连接信息:即用户新登录时,更新用户的Link信息(即登录所在Link的地址信息,消息转发时根据Link地址路由消息)。

2、 IM Server收到群消息后,按群ID将消息路由到“群消息服务”模块;

3、 群消息模块检查并预处理消息内容,然后通过“群成员在线状态”服务获取在线成员,完成消息转发的基础工作。为了减少群消息模块和群在线成员服务之间的网络流量,采用了“本地缓存+增量同步”的缓存策略,即本地缓存记录最后更新版本号和时间戳,每次同步群在线成员前先检查缓存版本号是否有变更,若有则按最后更新时间增量同步;

4、 通过“群成员在线服务”获取在线群成员的Link链接信息,按Link分组路由消息(分组路由的原因:同一Link上的全部群成员只需要路由一条消息即可)。同样为了减少网络开销,成员Link信息也采用“本地缓存+增量同步”的方案;

5、 群消息采用“漫游+历史”的存储方案,漫游的消息存储在分布式缓存中,历史消息异步写入HBase。用户登录后可以通过漫游快速的获取到最新消息,并可以通过拉取历史查看更早的消息。

二、万人群方案本地缓存增量同步策略
抛开群在线状态管理逻辑,群成员在线状态服务可以简单理解为分布式集中缓存,增量同步技术方案如下:

数据缓存是一个集合,其包含了多个缓存数据项,每一个数据项带有最后更新时间信息;另外缓存还有一个严格递增的版本号;
缓存数据变更(新增、修改、删除)后,需要增加版本号;
本地线程通过缓存管理读取数据时,管理服务先检查本地版本号和分布式缓存中的版本号是否一致,若不一致则按本地最新时间戳增量同步新数据项,并更新本地的版本号和最后更新时间(为了避免分布式集中缓存中并发写入导致的增量时间戳不可靠问题,增量更新时可以将本地记录的最后更新时间戳向前推移,比如减少20ms);
为避免本地多线程并发读取相同数据项导致并发更新本地缓存的问题,可以按缓存数据合并更新请求,即解决并发问题还可以减少网络开销;
缓存数据由大量数据项构成,为了避免单个缓存数据太大,可以将数据项中的属性业务场景精简(冷热分离),低频次读写的属性额外缓存。
三、万人群水平扩容方案
万人群采用大量本地缓存的方案解决消息处理性能和网络流量的问题,因此本地存储空间成了方案的瓶颈点。因此我们设计了分组路由的技术方案。
图片描述

消息按群ID和路由策略定向路由到指定分组(集群)上处理,分组由多个计算节点组成,因此方案上可以做到分组内和分组间的水平扩缩容。

四、IM专属云
由于万人群对计算和存储资源消耗比较高,在实施和运维方案上也有一定的特殊性,为了保证业务的可靠性和稳定性,万人大群仅提供给专属云客户。

网易云信IM专属云以亿级日活的公有云架构为基础,全面升级了业务技术架构和部署、运维方案,旨在为云信客户提供更加稳定的IM服务,采用专属云方案,将获得以下优势:

专属的独立计算资源:不仅计算资源独立,而且资源冗余度比公有云更高,且不会受到公有云上其他客户业务的影响;
专属的独立运维服务:专属云由资深的SRE团队成员负责,运维经验丰富,能够根据客户业务场景制定最佳的业务监控、弹性扩容、故障迁移等运维方案;
专属的IM能力:由于专属云下计算资源独立,业务场景特征明确,因此可以使用万人群、百万人聊天室等高级服务。
专属的活动保障:每年可以获得2次大型活动保障服务。

立即咨询,立享专属服务、专属资源以及万人大群。


网易数智
619 声望140 粉丝

欢迎关注网易云信 GitHub: