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

文章插图
第四步，我们通过分配规则 hash(id) mod 100 计算出对应的队列编号。
如果 hash(id) 的结果为 2000，那么算出的队列编号 m = 0。这时候，我们一查，发现对应编号 0 的 chat00 队列确实存在，那么就直接发送消息到 chat00 中。

文章插图
如果我们的 hash(id) 的结果为 1999，那么算出的队列编号 m = 99。此时，我们去查队列映射关系，发现 99 编号并没有对应的真实队列。这时候怎么办？很简单，我们顺时针继续往下找，找到谁了呢？0 对应的 chat00 队列，这是真实存在的，这时候，我们就将消息发送到 chat00 队列中。

文章插图
上面四步就是一个基本的一致性哈希算法了。
那么，这套一致性哈希算法满足我们不想总是更新消息分配规则的需求吗？让我们验证一下：
假设我们需要在消费信息端集群增加一台机器
我们如果要增加一台机器，那么同时我们也需要在 MQ 中增加一个队列。这时候，我们的分配规则是 hash(id) mod 100，增加了队列后，真实的队列数假设为 6。此时，如果 hash(id) mod 100 的结果小于 6，那么分配的规则和没有增加机器的时候规则一样，以前分配到哪个队列，现在还是分配到哪个队列。但是对于结果等于 6 的情况，则发生了变化。信息会被自动分配给 chat05。当分配给 chat05 后，新的消费者就会自动开始进入正常工作了，我们不需要做任何人工干预，也不需要考虑分配规则的变化。
增加机器以前：

文章插图
增加机器之后：

文章插图
假设消费信息端集群一台机器宕机了
模拟宕机，此时我们会去减少一个队列。减少后的真实队列数量为 5，则正好和增加队列相反，m = 5 时，那么行为不会有任何变化，以前分到哪个队列，还是分到哪个队列。如果 m = 6，由于已经不存在真实的队列了，就会做顺时针查找，结果找到 chat00，以前会分到 chat05 的就会被分到 chat00。而此时，chat00 由于正好有消费者，所以，系统的用户是毫无感知的，我们也专心修复我们机器即可。当机器恢复后，就会和新增机器一样，计算结果为 6 的信息会被重新分配回 chat05。
目前，我们可以看到，当我们引入一致性哈希后，我们不管新增机器还是集群机器宕机，我只需要跟随着机器的状态，做一个操作即可：增加或者减少 MQ 中的队列。一切简单化了。
那么，这个方案是否依然还有问题呢？
失衡的圆环，压垮骆驼的可能只是一根稻草
假设我们目前有 5 个队列存在，我们的分配规则是m = hash(id) mod 100。那么，此时，问题就出来了。
如果 m 的值大于 5，由于没有对应的真实队列存在，系统就会顺时针顺着我们构造出来的哈希环找，最终会找到 chat00 这个队列上。
然后，你会发现，只要是 m 值大于 5 的 id 对应用户发的信息，最终都会落入到 chat00 队列中。

文章插图
在极端情况下，如果大量的信息涌入到 chat00 队列里，由于对应 chat00 的消费者处理不过来，很可能会导致这个消费者的崩溃。
然后，去除队列后，根据规则，又会有大量的信息涌入到 chat00 后续的队列 chat01 里，这些信息又会导致 chat01 对应应用的崩溃，最终引发整个集群的崩溃，这就是雪崩效应。
我们需要一种更巧妙的办法来解决这个问题。
从实变虚，也许我们应该更敢想一些
经过上面的论述，我们发现，我们在分配队列时，之所以失衡，是因为我们的队列在圆环上的分配失衡。
我们所有的真实队列都是按照顺时针依次排布在圆环上的。在上面的场景里，我们只有 5 个队列。此时，我们假设会有 100 个队列。那么，m = hash(id) mod 100 这个公式里：
m 大于 5 的概率为 95%
由于我们的 5 个队列是按照编号顺序依次排列的。那就说明所有 m 大于 5 的信息就都会映射到一个不存在的队列上，最终，根据规则，顺时针滑到了 0 对应的 chat00 队列中。
如果，我们可以让真实存在的队列均匀分布到环上，那么，这种严重失衡的现象还会再出现吗？

文章插图

文章插图
从上面的图我们可以看出，如果我们能让真实的队列均匀的在圆环上分布，那么这种严重失衡的现象就会得到极大的缓解。