网易云信技术共享:为即时通讯中的成千上万人提供聊天技术解决方案的实践总结

时间:2020-10-20

即时通讯软件开发

 网易云信技术共享:为即时通讯中的成千上万人提供聊天技术解决方案的实践总结

 1.介绍

 在不了解即时通讯技术的人眼里,群聊只是一种常见的功能。应该不难实现吧?!

 实际上,从前端功能界面来看,群聊只不过是一对多的聊天消息分发模式,周期性地向群成员发送消息。什么是困难?

 事实上,群聊是即时通讯系统的技术难点之一。困难在哪里?是服务器!群聊功能的架构设计和技术实现质量在一定程度上可以代表该即时通讯软件的技术水平。

 在后台技术实现方面,群聊至少有以下困难:

 1)如何有效地分发大量群组成员的消息?

 2)如何有效管理群组成员的在线状态?

 3)如何有效地阅读小组成员的在线状态?

 4)在集群系统中,如何有效地保证群组成员信息的准确传递?

 5)群聊信息应该通过传播来书写还是阅读?

 6)如何确保在分发大量群聊消息时,单个聊天消息的体验不受影响?

 7)如何应对一大群突发事件下的性能负荷?

 ........

 目前,在市场上主流的即时通讯产品中,微信群限500人,QQ群限3000人(每年3000人升级,非常昂贵,不适合普通用户)。一方面,集团成员的数量不应超过产品的定义;另一方面,技术成本也是一个不可避免的因素。这个由一万人组成的超大群体的技术难度更难以想象。

 本文的内容是网易云信团队在设计和实施与成千上万人聊天的技术方案时总结的技术实践,以响应与成千上万人聊天的功能需求,并借此机会与所有即时消息开发人员分享。

 网易云信科技共享:g.jpeg IM _ tim万人聊天技术方案实践总结。

 2.概观

 随着移动互联网的发展,即时通讯服务已经广泛应用于各个行业,客户业务发展迅速。限制在100人或1000人的传统群聊已经不能满足许多业务发展需求。因此,网易云信即时通讯推出了万人服务。

 一万人需要解决以下问题:

 1)消息需要按照1:9999的比例转发和传递,按照传统的消息处理流程会产生大量的子任务,这需要极高的系统吞吐量;

 2)在微服务系统架构下,如果不采用一些优化方案,服务和存储(数据库、缓存等)之间的QPS和网络流量。)将会非常高;

 3)以组为单位的缓存(如组成员列表)的内存存储成本很大(假设一个成员为200字节,10,000人的人口约为2mb);

 4)群组成员登录后需要同步群组离线消息,智能手机上前后切换应用生成的登录同步消息协议很多,因此有必要对消息同步方案进行优化。

 为解决上述问题,万人技术方案采用“聚集+分层/群体+增量”的设计思路:

 网易云信技术共享:一万人聊天技术方案在IM _1.png的实践总结

 3.万人新闻处理流程

 1)按组维护在线组成员信息主要包括两部分(可以理解为两个缓存集):

 A.集团成员在线信息:当用户在线状态发生变化(在线和离线)时,更新相应集团的在线状态信息(即动态维护集团哪些成员在线);

 B.成员即时消息长连接信息:当用户新登录时,更新用户的链路信息(即用户登录的链路的地址信息,转发消息时根据链路地址路由消息)。

 2)即时消息服务器收到群组消息后,根据群组标识将消息路由到“群组消息服务”模块;

 3)群组消息模块对消息内容进行检查和预处理,然后通过“群组成员在线状态”服务获取在线成员,完成消息转发的基础工作。为了减少群组消息模块与群组在线成员服务之间的网络流量,采用了“本地缓存+增量同步”的缓存策略,即本地缓存记录上次更新的版本号和时间戳,并在每次同步群组在线成员之前检查缓存的版本号是否发生变化,如果发生变化,则根据上次更新的时间增量进行同步。

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

 5)群组消息采用“漫游+历史”的存储方案,漫游消息存储在分布式缓存中,历史消息异步写入糖化血红蛋白。登录后,用户可以通过漫游快速获取最新消息,并通过提取历史记录查看早期消息。

 4.万人口方案的本地缓存增量同步策略

 除了组存在管理逻辑之外,组成员存在服务可以简单地理解为分布式集中式缓存。

 增量同步的技术方案如下:

 网易云信技术共享:IM _2.png万人聊天技术方案实践总结

 如上图所示:

 1)数据缓存是一个集合,包含多个缓存的数据项,每个数据项携带最后更新时间信息;此外,缓存还具有严格递增的版本号;

 2)缓存数据发生变化(增加、修改或删除)后,需要增加版本号;

 3)当本地线程通过缓存管理读取数据时,管理服务首先检查本地版本号是否与分布式缓存中的版本号一致,如果不一致,则根据最新的本地时间戳增量同步新数据项,并更新本地版本号和上次更新时间(为了避免分布式集中式缓存中并发写入导致的增量时间戳不可靠,本地记录的上次更新时间戳可以向前移动,例如减少20毫秒);

 4)为了避免本地多线程并发读取同一数据项导致的本地缓存并发更新问题,可以根据缓存的数据合并更新请求,解决并发问题,降低网络开销;

 5)缓存数据由大量数据项组成。为了避免单个缓存数据太大,可以简化数据项中的属性业务场景(冷、热分离),并且可以额外缓存低频读写的属性。

 5.一万人的扩展计划

 数百万人使用大量的本地缓存方案来解决消息处理性能和网络流量的问题,因此本地存储空间成为该方案的瓶颈。为此,我们设计了分组路由技术方案。

 网易云信技术共享:IM _3.png万人聊天技术方案实践总结

 消息根据组标识和路由策略定向路由到指定的分组(簇)进行处理,分组由多个计算节点组成,因此该方案可以实现分组内部和分组之间的水平扩展和收缩。

 6.作为一项“云”服务,网易云信如何实现成千上万人所需的计算资源?

 由于10,000人对计算和存储资源的高消耗,在实施和操作维护方案中存在某些特殊性。为了确保业务的可靠性和稳定性,网易云信仅向独家云客户提供10,000人的能力(普通公共云客户无法使用)。

 网易云信的即时消息专有云之所以能够为成千上万的人提供硬件和软件基础设施保护,其原因在于它必须具备以下资源能力:

 1)需要专用的独立计算资源:保持计算资源的独立性,并具有比公共云更高的资源冗余度,确保它们不会受到公共云上其他客户服务的影响;

 2)需要专门的独立操作和维护服务,因此,最好的操作和维护方案,如业务监控、灵活扩展和故障迁移,是根据客户的业务场景制定的。

 总之,实现与成千上万人的聊天,优秀的技术方案设计和技术实现只是其中的一个方面,基本的计算设施资源和运行维护能力也是必不可少的。

 因此,从现在开始,不要只喊10,000人聊天,甚至100,000人聊天。如果你想实现,这是不可能的!