面试官常问的“一致性哈希”，都在这-18-张图里！，面试小技巧视频

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

1. RabbitMQ 是个单点，它一坏掉，整个系统就会全部瘫痪。
2. 收、发消息的业务系统也是单点。任何一点出现问题，对应队列的消息要么无从消费，要么海量消息堆积。

无论哪种问题，最终是整套分布式系统都无法使用，后续处理非常麻烦。

对于 RabbitMQ 的单点问题，由于当时 RabbitMQ 的集群功能非常弱，普通模式有 queue 本身的单点问题，所以，最终使用了 Keepalived 配合了两台无关系的 RabbitMQ 搞出了高可用。

而对于业务系统单点问题，从一开始着手解决的时候就出现了波折。一般来说，我们要解决单点问题，方法就是堆机器，堆应用。收发是单点，我们直接多部署几个应用就可以了。如果仅仅从技术上看，无非就是多个收发消息的应用大家一起竞争往 MQ 中放消息拿消息而已。

但是，恰恰就是在把收发消息的应用集群化后，系统出现了问题。

本身这套系统架构会被应用到公司的多类业务上，有些业务对消息的顺序有着苛刻的要求。

比如，公司内部的 IM 应用，不管是点对点的聊天还是群聊消息，都需要对话消息严格有序。而当我们把生产消息和消费消息的应用集群化后，问题出现了：

聊天记录出现了乱序

A 和 B 对话，会出现某些消息没有严格按照 A 发出的先后顺序被 B 接收，于是整个聊天顺序乱成了一锅粥。

经过排查，发现问题的根源就在于应用集群上。由于没有对应用集群收发消息做特殊的处理，当 A 发出一条聊天信息给B时，发送到 RabbitMQ 中的信息会被在 B 处的消费端所争抢。如果 A 在短时间内发出了几条信息，那么就可能会被集群中的不同应用抢走。

这时候，乱序的问题就出现了。虽然应用业务逻辑是相同的，但是这些集群中的应用依然可能在处理信息速度上出现差异，最终导致用户看到的聊天信息错乱。

问题找到了，解决办法是什么？

上面我们说过了，消息顺序错乱是因为集群中不同应用抢消息然后处理速度不一样导致的。如果我们能保证 A 和 B 会话，从开始之后到会话结束之前，永远只会被 B 所在的消费消息集群应用中的同一个应用消费，那么我们就能保证消息有序。这样一来，我们就可以在消费消息的那个应用中，对抢到的消息进行排队，然后依次处理。

那么，这种保证怎么实现呢？

首先，我们在 RabbitMQ 中会建立有相同前缀的队列，后面跟着队列编号。然后，集群中的不同应用会分别监听这两个有着不同编号的队列。当在 A 发送信息时，我们会对信息做一次简单的哈希:

m = hash(id) mod n

这里，id 是用户的标识。n 是集群中 B 所在业务系统部署的数量。最终的 m 是我们需要发送到的目的队列编号。

假设，hash(id) 的结果为 2000，n 为 2，经过计算 m = 0。此时，A 就会把他和 B 的对话信息都发送到 chat00 的队列里。B 收到消息后，就会依次显示给终端用户。这样，聊天乱序的问题就解决了。

那么，事情到此就结束了吗？这个解决方案是完美的吗？

2. 看来，我们需要增加应用数量了

随着公司的发展，公司的人数也急剧上升，公司内部的 IM 使用人数也跟着多了起来，新问题又随之出现了。

最主要的问题是，人们收到聊天信息的速度变慢了。原因也很简单，收取聊天信息的集群机器不够用了。解决办法可以简单直接点，再加台机器就好了。

不过，由于收消息的集群中新加入了一台机器，这时候，我们还需要额外多作一些事情：

1. 我们需要为新加入的这台机器上的应用额外再多增加一个队列 chat02。
   

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

3. 重新启动发送消息的项目，以便修改的规则生效。

4. 把收消息的应用部署到新机器上。
   

到这时，一切还都在可控范围。开发人员只需要在需要的时候，新增加个队列，然后把我们的分配规则小小的修改下即可。

但是，他们不知道的是，暴风雨就要来了。

3. 新的问题来了，也许这就是人生吧

由于公司内部很多人在使用这个 IM 工具。有些时候，为了方便，公司的客户还有一些合作方也用起了这个 IM。这让事情变得复杂了起来。起初，开发人员还是像往常一样，每当人们抱怨说收消息过慢的时候，他们就会加一台机器。

最糟糕的是，公司的客户也会抱怨，他们发现 IM 有时候彻底不可用。这可不是小事情。公司内部人员的问题还可以内部沟通解决。但是公司客户的问题，大意不得，因为这关系到公司产品的名誉。

那么，这到底是怎么一回事呢？

原来，根本原因还在于每次修改完配置规则后的重启服务。每次修改完配置规则，就需要规划好一个恰当的停机时间，去重新对项目做个上线。

但是，这种方法在公司的客户也使用这个 IM 后就行不通了。因为公司的客户有不少是在国外的。也就是说，不管白天还是深夜，很可能总是有人在使用这个 IM。

这就迫使开发人员们，在增加机器时，还需要去和多方协调沟通出一个上线时间，然后发布公告，再去上线。这种反复沟通，再上线，再反复沟通，再上线直接把开发人员们折腾了个半死。

往往沟通完，上线时间直接被放到了半个月以后。而在这半个月里，开发人员还要承受无数内部 IM 使用人的口水。费心竭力的沟通，声嘶力竭的解释，缺眠少觉的上线，这一切的一切推动着开发人员们必须对眼前这套技术方案作出改变了。

4. 思路转起来，队列环起来

新的技术方案的需求本质就是：

无论是分配消息规则变化还是集群机器添加都不能停机停服务

对于这种情况，一个很好的解决方案就是如果我们对项目配置文件进行动态的定时检测，当发现变动时，刷新配置规则即可。

一切看上去很美好，采用了动态的定时检测后，每当我们需要新增集群中的机器时，我们只需要如下三个步骤了:

1. 增加一个队列
2. 修改分配消息的规则
3. 部署新的机器

客户毫无感知，开发人员们也不需要和用户们协调沟通出专门的上线安排。可是，这个方案也存在一些问题：

1. 随着我们的系统部署越来越多，我们需要手工修改规则的系统也越来越多。
2. 如果消费机器宕机了，我们需要删除队列，同时还需要去删除修改分配消息的规则，等到机器恢复了，我们还要再把分配消息的规则改回去。

这个分配消息的规则真讨厌啊，每次有变动，就要去关心这个分配消息的规则。有没有什么办法能把这个分配变得更自动化一些呢？

如果我们假设在 MQ 中有 100 个收发聊天信息的队列（100：这是对我们的IM不可能达到的一个数字），我们只需要在配置规则中配置成：

hash(id) mod 100

然后，我们的发送消息的应用启动后，去动态的探测出真实的所有收发聊天信息的队列信息。

当我们通过哈希算出的编号发现没有真实对应的队列存在时，就根据一定的规则，去找到一个真实存在的队列，这个队列，就是我们要发消息的队列。

如果我们做到这样，那么以后，每次队列有变化，无论增多还是减少，我们都不需要再去考虑分配规则的事情了，只需要移除有问题的队列或者增加有对应消费者的队列即可。

这个思想，就是一致性哈希的思想。

具体怎么做呢？

第一步，我们假设有个 100 个收发聊天信息的队列，并且这些队列处于一个环上。

第二步，我们获取到真实的收发聊天信息的队列数量，假设有 5 个。

第三步，我们把真实的队列映射到我们第一步假设的环中。

第四步，我们通过分配规则 hash(id) mod 100 计算出对应的队列编号。

如果 hash(id) 的结果为 2000，那么算出的队列编号 m = 0。这时候，我们一查，发现对应编号 0 的 chat00 队列确实存在，那么就直接发送消息到 chat00 中。

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

上面四步就是一个基本的一致性哈希算法了。

那么，这套一致性哈希算法满足我们不想总是更新消息分配规则的需求吗？让我们验证一下：

1. 假设我们需要在消费信息端集群增加一台机器
   我们如果要增加一台机器，那么同时我们也需要在 MQ 中增加一个队列。这时候，我们的分配规则是 hash(id) mod 100，增加了队列后，真实的队列数假设为 6。此时，如果 hash(id) mod 100 的结果小于 6，那么分配的规则和没有增加机器的时候规则一样，以前分配到哪个队列，现在还是分配到哪个队列。但是对于结果等于 6 的情况，则发生了变化。信息会被自动分配给 chat05。当分配给 chat05 后，新的消费者就会自动开始进入正常工作了，我们不需要做任何人工干预，也不需要考虑分配规则的变化。

增加机器以前：

总结

机会是留给有准备的人，大家在求职之前应该要明确自己的态度，熟悉求职流程，做好充分的准备，把一些可预见的事情做好。

对于应届毕业生来说，校招更适合你们，因为绝大部分都不会有工作经验，企业也不会有工作经验的需求。同时，你也不需要伪造高大上的实战经验，以此让自己的简历能够脱颖而出，反倒会让面试官有所怀疑。

你在大学时期应该明确自己的发展方向，如果你在大一就确定你以后想成为Java工程师，那就不要花太多的时间去学习其他的技术语言，高数之类的，不如好好想着如何夯实Java基础。下图涵盖了应届生乃至转行过来的小白要学习的Java内容：

请转发本文支持一下

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）**
[外链图片转存中…(img-NV9Mpdy0-1713558576763)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！