Redis 的高可用太重要啦之前找工作面试这个问题面试的频率都能排到前几尤其是一些大厂先不要着急看文章如果面试官给你抛这么个问题你会怎么回答呢可以先想 5 分钟。这里要等待 5 分钟 ...其实我也可以偷个懒完全转载其它博客但是没有找到我想要的为了不辜负广大粉丝楼哥还是单独给大家写一篇主要根据这块知识再结合之前的一些面试情况给大家唠唠。1. Redis 分片策略1.1 Hash 分片我们都知道对于 Reids 集群我们需要通过 hash 策略将 key 打在 Redis 的不同分片上。假如我们有 3 台机器常见的分片方式为 hash(IP)%3其中 3 是机器总数。目前很多小公司都这么玩上手快简单粗暴但是这种方式有一个致命的缺点当增加或者减少缓存节点时总节点个数发生变化导致分片值发生改变需要对缓存数据做迁移。那如何解决该问题呢答案是一致性 Hash。1.2 一致性 Hash一致性哈希算法是 1997 年由麻省理工学院提出的一种分布式哈希实现算法。环形空间按照常用的 hash 算法来将对应的 key 哈希到一个具有 2^32 次方个桶的空间中即 0~(2^32)-1 的数字空间中现在我们可以将这些数字头尾相连想象成一个闭合的环形。Key 散列 Hash 环现在我们将 object1、object2、object3、object4 四个对象通过特定的 Hash 函数计算出对应的 key 值然后散列到 Hash 环上。机器散列 Hash 环假设现在有 NODE1、NODE2、NODE3 三台机器以顺时针的方向计算将所有对象存储到离自己最近的机器中object1 存储到了 NODE1object3 存储到了 NODE2object2、object4 存储到了 NODE3。节点删除如果 NODE2 出现故障被删除了object3 将会被迁移到 NODE3 中这样仅仅是 object3 的映射位置发生了变化其它的对象没有任何的改动。添加节点如果往集群中添加一个新的节点 NODE4object2 被迁移到了 NODE4 中其它对象保持不变。通过对节点的添加和删除的分析一致性哈希算法在保持了单调性的同时还使数据的迁移达到了最小这样的算法对分布式集群来说是非常合适的避免了大量数据迁移减小了服务器的的压力。如果机器个数太少为了避免大量数据集中在几台机器实现平衡性可以建立虚拟节点比如一台机器建立 3-4 个虚拟节点然后对虚拟节点进行 Hash。2. 高可用方案很多时候公司只给我们提供一套 Redis 集群至于如何计算分片我们一般有 2 套成熟的解决方案。客户端方案也就是客户端自己计算 Redis 分片无论你使用Hash 分片还是一致性 Hash都是由客户端自己完成。客户端方案简单粗暴但是只能在单一语言系统之间复用如果你使用的是 PHP 的系统后来 Java 也需要使用你需要用 Java 重新写一套分片逻辑。为了解决多语言、不同平台复用的问题就衍生出中间代理层方案。中间代理层方案将客户端解决方案的经验移植到代理层中通过通用的协议如 Redis 协议来实现在其他语言中的复用用户无需关心缓存的高可用如何实现只需要依赖你的代理层即可。代理层主要负责读写请求的路由功能并且在其中内置了一些高可用的逻辑。你可以看看你们公司的 Redis 使用的是哪种方案呢对于“客户端方案”其实有的也不用自己去写比如负责维护 Redis 的部门会提供不同语言的 SDK你只需要去集成对应的 SDK 即可。3. 高可用原理3.1 Redis 主从Redis 基本都通过“主 - 从”模式进行部署主从库之间采用的是读写分离的方式。同 MySQL 类似主库支持写和读从库只支持读数据会先写到主库然后定时同步给从库具体的同步规则主要将 RDB 日志从主库同步给从库然后从库读取 RDB 日志这里比较复杂其中还涉及到 replication buffer就不再展开。这里有个问题一次同步过程中主库需要完成 2 个耗时操作生成 RDB 文件和传输 RDB 文件。如果从库数量过多主库忙于 fock 子进程生成 RDB 文件和数据同步会阻塞主库正常请求。这个如何解决呢答案是 “主 - 从 - 从” 模式。为了避免所有从库都从主库同步 RDB 日志可以借助从库来完成同步比如新增 3、4 两个 Slave可以等 Slave 2 同步完后再通过 Slave 2 同步给 Slave 3 和 Slave 4。如果我是面试官我可能会继续问如果数据同步了 80%网络突然终端当网络后续又恢复后Redis 会如何操作呢3.2 Redis 分片这个有点像 MySQL 分库分表将数据存储到不同的地方避免查询时全部集中到一个实例。其实还有一个好处就是数据进行主从同步时如果 RDB 数据过大会严重阻塞主线程如果用分片的方式可以将数据分摊比如原来有 10 GB 的数据分摊后每个分片只有 2 GB。可能有同学会问Redis 分片和“主 - 从”模式有啥关系呢你可以理解图中的每个分片都是主库每个分片都有自己的“主 - 从”模式结构。那么数据如何找到对应的分片呢前面其实已经讲过假如我们有 3 台机器常见的分片方式为 hash(IP)%3其中 3 是机器总数hash 值为机器 IP这样每台机器就有自己的分片号。对于 key也可以采用同样的方式找到对应的机器分片号 hash(key)%3hash 算法有很多可以用 CRC16(key)也可以直接取 key 中的字符通过 ASCII 码转换成数字。3.3 Redis 哨兵机制3.3.1 什么是哨兵机制 在主从模式下如果 master 宕机了从库不能从主库同步数据主库也不能提供读写功能。怎么办呢 这时就需要引入哨兵机制 哨兵节点是特殊的 Redis 服务不提供读写服务主要用来监控 Redis 实例节点。那么当 master 宕机哨兵如何执行呢3.3.2 判断主机下线哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况用来判断实例的状态如果哨兵发现主库或从库对 PING 命令的响应超时了哨兵就会先把它标记为“主观下线”。那是否一个哨兵判断为“主观下线”就直接下线 master 呢答案肯定是不行的需要遵循 “少数服从多数” 原则有 N/21 个实例判断主库“主观下线”才判定主库为“客观下线”。比如上图有 3 个哨兵有 2 个判断 “主观下线”那么就标记主库为 “客观下线”。3.3.3 选取新主库我们有 5 个从库需要选取一个最优的从库作为主库分 2 步筛选检查从库的当前在线状态和之前的网络连接状态过滤不适合的从库打分根据从库优先级、和旧主库的数据同步接近度进行打分选最高分作为主库。如果分数一致怎么办 Redis 也有一个策略ID 号最小的从库得分最高会被选为新主库。当 slave 3 选举为新主库后会通知其它从库和客户端对外宣布自己是新主库大家都得听我的哈 Redis 高可用原理？
Redis 的高可用太重要啦之前找工作面试这个问题面试的频率都能排到前几尤其是一些大厂先不要着急看文章如果面试官给你抛这么个问题你会怎么回答呢可以先想 5 分钟。这里要等待 5 分钟 ...其实我也可以偷个懒完全转载其它博客但是没有找到我想要的为了不辜负广大粉丝楼哥还是单独给大家写一篇主要根据这块知识再结合之前的一些面试情况给大家唠唠。1. Redis 分片策略1.1 Hash 分片我们都知道对于 Reids 集群我们需要通过 hash 策略将 key 打在 Redis 的不同分片上。假如我们有 3 台机器常见的分片方式为 hash(IP)%3其中 3 是机器总数。目前很多小公司都这么玩上手快简单粗暴但是这种方式有一个致命的缺点当增加或者减少缓存节点时总节点个数发生变化导致分片值发生改变需要对缓存数据做迁移。那如何解决该问题呢答案是一致性 Hash。1.2 一致性 Hash一致性哈希算法是 1997 年由麻省理工学院提出的一种分布式哈希实现算法。环形空间按照常用的 hash 算法来将对应的 key 哈希到一个具有 2^32 次方个桶的空间中即 0~(2^32)-1 的数字空间中现在我们可以将这些数字头尾相连想象成一个闭合的环形。Key 散列 Hash 环现在我们将 object1、object2、object3、object4 四个对象通过特定的 Hash 函数计算出对应的 key 值然后散列到 Hash 环上。机器散列 Hash 环假设现在有 NODE1、NODE2、NODE3 三台机器以顺时针的方向计算将所有对象存储到离自己最近的机器中object1 存储到了 NODE1object3 存储到了 NODE2object2、object4 存储到了 NODE3。节点删除如果 NODE2 出现故障被删除了object3 将会被迁移到 NODE3 中这样仅仅是 object3 的映射位置发生了变化其它的对象没有任何的改动。添加节点如果往集群中添加一个新的节点 NODE4object2 被迁移到了 NODE4 中其它对象保持不变。通过对节点的添加和删除的分析一致性哈希算法在保持了单调性的同时还使数据的迁移达到了最小这样的算法对分布式集群来说是非常合适的避免了大量数据迁移减小了服务器的的压力。如果机器个数太少为了避免大量数据集中在几台机器实现平衡性可以建立虚拟节点比如一台机器建立 3-4 个虚拟节点然后对虚拟节点进行 Hash。2. 高可用方案很多时候公司只给我们提供一套 Redis 集群至于如何计算分片我们一般有 2 套成熟的解决方案。客户端方案也就是客户端自己计算 Redis 分片无论你使用Hash 分片还是一致性 Hash都是由客户端自己完成。客户端方案简单粗暴但是只能在单一语言系统之间复用如果你使用的是 PHP 的系统后来 Java 也需要使用你需要用 Java 重新写一套分片逻辑。为了解决多语言、不同平台复用的问题就衍生出中间代理层方案。中间代理层方案将客户端解决方案的经验移植到代理层中通过通用的协议如 Redis 协议来实现在其他语言中的复用用户无需关心缓存的高可用如何实现只需要依赖你的代理层即可。代理层主要负责读写请求的路由功能并且在其中内置了一些高可用的逻辑。你可以看看你们公司的 Redis 使用的是哪种方案呢对于“客户端方案”其实有的也不用自己去写比如负责维护 Redis 的部门会提供不同语言的 SDK你只需要去集成对应的 SDK 即可。3. 高可用原理3.1 Redis 主从Redis 基本都通过“主 - 从”模式进行部署主从库之间采用的是读写分离的方式。同 MySQL 类似主库支持写和读从库只支持读数据会先写到主库然后定时同步给从库具体的同步规则主要将 RDB 日志从主库同步给从库然后从库读取 RDB 日志这里比较复杂其中还涉及到 replication buffer就不再展开。这里有个问题一次同步过程中主库需要完成 2 个耗时操作生成 RDB 文件和传输 RDB 文件。如果从库数量过多主库忙于 fock 子进程生成 RDB 文件和数据同步会阻塞主库正常请求。这个如何解决呢答案是 “主 - 从 - 从” 模式。为了避免所有从库都从主库同步 RDB 日志可以借助从库来完成同步比如新增 3、4 两个 Slave可以等 Slave 2 同步完后再通过 Slave 2 同步给 Slave 3 和 Slave 4。如果我是面试官我可能会继续问如果数据同步了 80%网络突然终端当网络后续又恢复后Redis 会如何操作呢3.2 Redis 分片这个有点像 MySQL 分库分表将数据存储到不同的地方避免查询时全部集中到一个实例。其实还有一个好处就是数据进行主从同步时如果 RDB 数据过大会严重阻塞主线程如果用分片的方式可以将数据分摊比如原来有 10 GB 的数据分摊后每个分片只有 2 GB。可能有同学会问Redis 分片和“主 - 从”模式有啥关系呢你可以理解图中的每个分片都是主库每个分片都有自己的“主 - 从”模式结构。那么数据如何找到对应的分片呢前面其实已经讲过假如我们有 3 台机器常见的分片方式为 hash(IP)%3其中 3 是机器总数hash 值为机器 IP这样每台机器就有自己的分片号。对于 key也可以采用同样的方式找到对应的机器分片号 hash(key)%3hash 算法有很多可以用 CRC16(key)也可以直接取 key 中的字符通过 ASCII 码转换成数字。3.3 Redis 哨兵机制3.3.1 什么是哨兵机制 在主从模式下如果 master 宕机了从库不能从主库同步数据主库也不能提供读写功能。怎么办呢 这时就需要引入哨兵机制 哨兵节点是特殊的 Redis 服务不提供读写服务主要用来监控 Redis 实例节点。那么当 master 宕机哨兵如何执行呢3.3.2 判断主机下线哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况用来判断实例的状态如果哨兵发现主库或从库对 PING 命令的响应超时了哨兵就会先把它标记为“主观下线”。那是否一个哨兵判断为“主观下线”就直接下线 master 呢答案肯定是不行的需要遵循 “少数服从多数” 原则有 N/21 个实例判断主库“主观下线”才判定主库为“客观下线”。比如上图有 3 个哨兵有 2 个判断 “主观下线”那么就标记主库为 “客观下线”。3.3.3 选取新主库我们有 5 个从库需要选取一个最优的从库作为主库分 2 步筛选检查从库的当前在线状态和之前的网络连接状态过滤不适合的从库打分根据从库优先级、和旧主库的数据同步接近度进行打分选最高分作为主库。如果分数一致怎么办 Redis 也有一个策略ID 号最小的从库得分最高会被选为新主库。当 slave 3 选举为新主库后会通知其它从库和客户端对外宣布自己是新主库大家都得听我的哈