如何保障分布式IM聊天系统的消息有序性（即消息不乱）原创

如何保障分布式I'M聊天系统的消息有序性及消息不乱？分布式I'M聊天系统中硬消息怎么做到不丢、不中，还按顺序到达？这个问题涉及到I'M系统的两个核心，一、消息不能丢，可靠性，二、顺序不能乱。有序性这要的痛点是I'M聊天系统架构的命门所在。本片主要总结和分享分布式I'M聊天系统架构中关于消息有序性的设计和实践。早期做消息有序，很多人第一反应是搞个全局发号器，所有消息排一队，挨个编号再发。理想很丰满，现实很骨感。高并发下，婴幼而上，抢号，发号器直接被打满，更致命的是，他一旦宕机，全亮路雪崩。这就像春运火车站只开一个售票窗，再快也撑不过3分钟。所以我们必须换思路，不搞大一统，而是分片独立法号，让每个窗口自给自足，互不干扰。混乱问题本质是什么？一定要串行档，一个响，并发冲，天然冲突。这时候有人会说，那我加个全局排序服务不就行了？可以，但代价太大，一个中心节点最多撑几万QPS，面对百万群聊一级用户，还没上线就已过载。所以全局有序不是解，而是加锁，我们要的不是天下大同，而是各聊各得，别乱就行，真正的突破口在于我们根本不需要全局有序，只需要绘画内有序。这就引出了经典策略，分而治之加局部有序，具体怎么做？

两步走稳第一步，业务分区哈希分片锁定归属，用30ID做一致性哈希，确保同一个绘画的所有消息始中路由到同一个处理节点，按绘画ID做哈希，算出该消息该由哪个节点处理，同一绘画哈希值一样路由到同一台机器，所有消息串行处理，天然避免跨节点乱序。第二步，局部序号独立发号局部递增，每个绘画独立维护一个计数器，每来一条消息就加一作为它的官方序号，每个绘画可以配一个独立计数器，比如VDC的iner，每来一条消息就加一生成为EICQ客户端，不管什么时候收到消息，指认这个序号，按序号从小到大排列展示。总结一下这套方案的核心思想就一句话，不要为假需求买单，我们不需要全局有序，只需要业务上有意义的有序，你看微信钉钉、飞书，哪一个是把全平台消息排成一条队列的，没有，他们都选择。

得到绘画及隔离加局部有序的设计，这才是工业级系统的通用解法。最后一张图串起全流程，从发起到渲染，全程围绕绘画、隔离和局部发号展开，每一个环节都在为同一个目标服务，在分布式环境下，低成本实现用户可感知的顺序正确。