分布式|优秀！一鼓作气学会“一致性哈希”，就靠这 18 张图了( 二 ) 单点|乱序|rabbitmq|学会

不过，由于收消息的集群中新加入了一台机器，这时候，我们还需要额外多做一些事情：
我们需要为新加入的这台机器上的应用额外再多增加一个队列 chat02。

文章插图
我们还需要修改下我们的分配消息的规则，把原来的 hash(id) mod 2 修改为 hash(id) mod 3。

文章插图
重新启动发送消息的项目，以便修改的规则生效。
把收消息的应用部署到新机器上。

文章插图
到这时，一切还都在可控范围。开发人员只需要在需要的时候，新增加个队列，然后把我们的分配规则小小的修改下即可。
但是，他们不知道的是，暴风雨就要来了。
新的问题来了，也许这就是人生吧
由于公司内部很多人在使用这个 IM 工具。有些时候，为了方便，公司的客户还有一些合作方也用起了这个 IM。这让事情变得复杂了起来。起初，开发人员还是像往常一样，每当人们抱怨说收消息过慢的时候，他们就会加一台机器。
最糟糕的是，公司的客户也会抱怨，他们发现 IM 有时候彻底不可用。这可不是小事情。公司内部人员的问题还可以内部沟通解决。但是公司客户的问题，大意不得，因为这关系到公司产品的名誉。
那么，这到底是怎么一回事呢？
原来，根本原因还在于每次修改完配置规则后的重启服务。每次修改完配置规则，就需要规划好一个恰当的停机时间，去重新对项目做个上线。
但是，这种方法在公司的客户也使用这个 IM 后就行不通了。因为公司的客户有不少是在国外的。也就是说，不管白天还是深夜，很可能总是有人在使用这个 IM。
这就迫使开发人员们，在增加机器时，还需要去和多方协调沟通出一个上线时间，然后发布公告，再去上线。这种反复沟通，再上线，再反复沟通，再上线直接把开发人员们折腾了个半死。
往往沟通完，上线时间直接被放到了半个月以后。而在这半个月里，开发人员还要承受无数内部 IM 使用人的口水。费心竭力的沟通，声嘶力竭的解释，缺眠少觉的上线，这一切的一切推动着开发人员们必须对眼前这套技术方案作出改变了。
思路转起来，队列环起来
新的技术方案的需求本质就是：
无论是分配消息规则变化还是集群机器添加都不能停机停服务
对于这种情况，一个很好的解决方案就是如果我们对项目配置文件进行动态的定时检测，当发现变动时，刷新配置规则即可。
一切看上去很美好，采用了动态的定时检测后，每当我们需要新增集群中的机器时，我们只需要如下三个步骤了:
增加一个队列
修改分配消息的规则
部署新的机器
客户毫无感知，开发人员们也不需要和用户们协调沟通出专门的上线安排。可是，这个方案也存在一些问题：
随着我们的系统部署越来越多，我们需要手工修改规则的系统也越来越多。
如果消费机器宕机了，我们需要删除队列，同时还需要去删除修改分配消息的规则，等到机器恢复了，我们还要再把分配消息的规则改回去。
这个分配消息的规则真讨厌啊，每次有变动，就要去关心这个分配消息的规则。有没有什么办法能把这个分配变得更自动化一些呢？
如果我们假设在 MQ 中有 100 个收发聊天信息的队列（100：这是对我们的IM不可能达到的一个数字），我们只需要在配置规则中配置成：
m = hash(id) mod 100
然后，我们的发送消息的应用启动后，去动态的探测出真实的所有收发聊天信息的队列信息。
当我们通过哈希算出的编号发现没有真实对应的队列存在时，就根据一定的规则，去找到一个真实存在的队列，这个队列，就是我们要发消息的队列。
如果我们做到这样，那么以后，每次队列有变化，无论增多还是减少，我们都不需要再去考虑分配规则的事情了，只需要移除有问题的队列或者增加有对应消费者的队列即可。
这个思想，就是一致性哈希的思想。
具体怎么做呢？
第一步，我们假设有个 100 个收发聊天信息的队列，并且这些队列处于一个环上。

文章插图
第二步，我们获取到真实的收发聊天信息的队列数量，假设有 5 个。
第三步，我们把真实的队列映射到我们第一步假设的环中。