本文探讨了在大用户量、高并发场景下构建IM群聊系统的挑战，包括实时写扩散问题和万人大群的管理。介绍了系统架构，包括Client、Proxy、Broker、Router、Gateway等角色，以及它们之间的交互。系统采用UDP通信，不存储消息，但面临扩容和系统稳定性的挑战。为了提高可靠性，提出了心跳检测和伪用户ID监控延迟的方法，以及基于UDP的可靠消息传输流程。
要实现一整套能用于大用户量、高并发场景下的IM群聊，技术难度远超IM系统中的其它功能，原因在于：IM群聊消息的实时写扩散特性带来了一系列技术难题。
举个例子：如一个2000人群里，一条普通消息的发出问题，将瞬间写扩散为2000条消息的接收问题，如何保证这些消息的及时、有序、高效地送达，涉及到的技术问题点实在太多，更别说个别场景下万人大群里的炸群消息难题了更别说个别场景下万人大群里的炸群消息难题了。
这也是为什么一般中大型IM系统中，都会将群聊单独拎出来考虑架构的设计，单独有针对性地进行架构优化，从而降低整个系统的设计难度。
所谓的群聊消息系统，就是一种多对多群体聊天方式，譬如直播房间内的聊天室对应的服务器端就是一个群聊消息系统。
系统名词解释：
1）Client : 消息发布者【或者叫做服务端群聊消息系统调用者】，publisher；
2）Proxy :系统代理，对外统一接口，收集Client发来的消息转发给Broker；
3）Broker ：系统消息转发Server，Broker 会根据 Gateway Message 组织一个 RoomGatewayList【key为RoomID，value为 Gateway IP：Port 地址列表】，然后把 Proxy 发来的消息转发到 Room 中所有成员登录的所有 Gateway；
<
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
