共计 1831 个字符，预计需要花费 5 分钟才能阅读完成。
在不理解 IM 技术的人眼里，群聊是再平时不过的性能而已，万人群聊？应该也不难实现吧？！
的确，从前端性能界面上来看，群聊无非就是个循环向群员发送音讯的一对多聊天音讯散发模式而已，难在何处？
实在的状况是，群聊是 IM 零碎中的高难度技术点之一。难在哪？难在服务端！从某种角度上说，群聊性能的架构设计和技术实现的品质，能够代表这款 IM 软件的技术水平。
群聊从后盾的技术实现上说，至多有以下难点：
1）如何高效地进行大量群员音讯的散发？2）如何高效地治理群员的在线状态？3）如何高效地读取群员的在线状态？4）集群零碎中，如何高效地保障群员音讯的精确送达？5）群聊音讯该扩散写还是扩散读？6）如何保障大量群聊音讯散发的状况下不影响单聊音讯体验？7）如何应答大群突发事件下的性能负载？.... ....
目前，市面上支流的 IM 产品中，微信群是 500 人下限，QQ 群是 3000 人下限（3000 人群是按年付费降级，很贵，不是为个别用户筹备的）。一方面，从产品的定义上群成员数量不应过多，另一方面，技术老本也是个不可回避的因素。万人群这种超大规模群的技术难度，更是难已设想。
随着挪动互联网的倒退，即时通讯服务被广泛应用到各个行业，客户业务疾速倒退，传统百人或千人下限的群聊曾经无奈满足很多业务倒退需要，因而网易云信 IM 推出万人群服务。即时通讯聊天软件开发能够征询蔚可云开发。
万人群场景须要解决以下问题：
1）音讯须要按 1:9999 的比例进行转发投递，按惯例音讯解决流程将产生大量的子工作，对系统吞吐量的要求极高；
2）在微服务零碎架构下，如果不采纳一些优化计划，服务以及存储（DB、缓存等）之间的 QPS 和网络流量将十分高；
3）以群为单位的缓存（如群成员列表）内存存储开销较大（假如一个成员 200Byte，万人群约 2MB）；
4）群成员登录后须要同步群离线音讯，智能手机上 App 前后台切换产生的较多登录同步音讯协定，因而须要优化音讯同步计划。
万人群音讯的解决流程
1）按群保护在线群成员信息，次要蕴含两局部（能够了解为两个缓存汇合）：
a. 群成员在线信息：即用户在线状态变动（上线、下线）时，更新相应群的在线状态信息（即动静保护群有哪些成员在线）；b. 成员 IM 长连贯信息：即用户新登录时，更新用户的 Link 信息（即登录所在 Link 的地址信息，音讯转发时依据 Link 地址路由音讯）。2）IM Server 收到群音讯后，按群 ID 将音讯路由到“群音讯服务”模块；
3）群音讯模块查看并预处理音讯内容，而后通过“群成员在线状态”服务获取在线成员，实现音讯转发的根底工作。为了缩小群音讯模块和群在线成员服务之间的网络流量，采纳了“本地缓存 + 增量同步”的缓存策略，即本地缓存记录最初更新版本号和工夫戳，每次同步群在线成员前先查看缓存版本号是否有变更，若有则按最初更新工夫增量同步；
4）通过“群成员在线服务”获取在线群成员的 Link 链接信息，按 Link 分组路由音讯（分组路由的起因：同一 Link 上的全副群成员只须要路由一条音讯即可）。同样为了缩小网络开销，成员 Link 信息也采纳“本地缓存 + 增量同步”的计划；
5）群音讯采纳“漫游 + 历史”的存储计划，漫游的音讯存储在分布式缓存中，历史音讯异步写入 HBase。用户登录后能够通过漫游疾速的获取到最新消息，并能够通过拉取历史查看更早的音讯。
万人群计划本地缓存增量同步策略
抛开群在线状态治理逻辑，群成员在线状态服务能够简略了解为分布式集中缓存。
1）数据缓存是一个汇合，其蕴含了多个缓存数据项，每一个数据项带有最初更新工夫信息；另外缓存还有一个严格递增的版本号；
2）缓存数据变更（新增、批改、删除）后，须要减少版本号；
3）本地线程通过缓存治理读取数据时，治理服务先查看本地版本号和分布式缓存中的版本号是否统一，若不统一则按本地最新工夫戳增量同步新数据项，并更新本地的版本号和最初更新工夫（为了免分布式集中缓存中并发写入导致的增量工夫戳不牢靠问题，增量更新时能够将本地记录的最初更新工夫戳向前推移，比方缩小 20ms）；
4）为防止本地多线程并发读取雷同数据项导致并发更新本地缓存的问题，能够按缓存数据合并更新申请，即解决并发问题还能够缩小网络开销；
5）缓存数据由大量数据项形成，为了防止单个缓存数据太大，能够将数据项中的属性业务场景精简（冷热拆散），低频次读写的属性额定缓存。
万人群程度扩容计划
万人群采纳大量本地缓存的计划解决音讯解决性能和网络流量的问题，因而本地存储空间成了计划的瓶颈点。
