在不了解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）缓存数据由大量数据项构成，为了避免单个缓存数据太大，可以将数据项中的属性业务场景精简（冷热分离），低频次读写的属性额外缓存。
万人群水平扩容方案
万人群采用大量本地缓存的方案解决消息处理性能和网络流量的问题，因此本地存储空间成了方案的瓶颈点。