phphash算法ip技巧_Redis 高可用事理

这里要等待 5 分钟 ...

实在我也可以偷个1. Redis 分片策略1.1 Hash 分片

我们都知道，对付 Redis 集群，我们须要通过 hash 策略，将 key 打在 Redis 的不同分片上。

如果我们有 3 台机器，常见的分片办法为 hash(IP)%3，个中 3 是机器总数。

目前很多小公司都这么玩，上手快，大略粗暴，但是这种办法有一个致命的缺陷：当增加或者减少缓存节点时，总节点个数发生变革，导致分片值发生改变，须要对缓存数据做迁移。

那如何办理该问题呢，答案是同等性 Hash。

同等性哈希算法是 1997 年由麻省理工学院提出的一种分布式哈希实现算法。

环形空间：按照常用的 hash 算法来将对应的 key 哈希到一个具有 2^32 次方个桶的空间中，即 0~(2^32)-1 的数字空间中，现在我们可以将这些数字头尾相连，想象成一个闭合的环形。

Key 散列 Hash 环：现在我们将 object1、object2、object3、object4 四个工具通过特定的 Hash 函数打算出对应的 key 值，然后散列到 Hash 环上。

机器散列 Hash 环：假设现在有 NODE1、NODE2、NODE3 三台机器，以顺时针的方向打算，将所有工具存储到离自己最近的机器中，object1 存储到了 NODE1，object3 存储到了 NODE2，object2、object4 存储到了 NODE3。

节点删除：如果 NODE2 涌现故障被删除了，object3 将会被迁移到 NODE3 中，这样仅仅是 object3 的映射位置发生了变革，其它的工具没有任何的改动。

添加节点：如果往集群中添加一个新的节点 NODE4，object2 被迁移到了 NODE4 中，其它工具保持不变。

通过对节点的添加和删除的剖析，同等性哈希算法在保持了单调性的同时，还使数据的迁移达到了最小，这样的算法对分布式集群来说是非常得当的，避免了大量数据迁移，减小了做事器的的压力。

如果机器个数太少，为了避免大量数据集中在几台机器，实现平衡性，可以建立虚拟节点（比如一台机器建立 3-4 个虚拟节点），然后对虚拟节点进行 Hash。

很多时候，公司只给我们供应一套 Redis 集群，至于如何打算分片，我们一样平常有 2 套成熟的办理方案。

客户端方案：也便是客户端自己打算 Redis 分片，无论你利用Hash 分片，还是同等性 Hash，都是由客户端自己完成。

客户端方案大略粗暴，但是只能在单一措辞系统之间复用，如果你利用的是 PHP 的系统，后来 Java 也须要利用，你须要用 Java 重新写一套分片逻辑。

为理解决多措辞、不同平台复用的问题，就衍生出中间代理层方案。

中间代理层方案：将客户端办理方案的履历移植到代理层中，通过通用的协议（如 Redis 协议）来实现在其他措辞中的复用，用户无需关心缓存的高可用如何实现，只须要依赖你的代理层即可。

代理层紧张卖力读写要求的路由功能，并且在个中内置了一些高可用的逻辑。

你可以看看，你们公司的 Redis 利用的是哪种方案呢？对付“客户端方案”，实在有的也不用自己去写，比如卖力掩护 Redis 的部门会供应不同措辞的 SDK，你只须要去集成对应的 SDK 即可。

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 会如何操作呢？

这个有点像 MySQL 分库分表，将数据存储到不同的地方，避免查询时全部集中到一个实例。

实在还有一个好处，便是数据进行主从同步时，如果 RDB 数据过大，会严重壅塞主线程，如果用分片的办法，可以将数据分摊，比如原来有 10 GB 的数据，分摊后，每个分片只有 2 GB。

可能有同学会问，Redis 分片，和“主 - 从”模式有啥关系呢？ 你可以理解，图中的每个分片都是主库，每个分片都有自己的“主 - 从”模式构造。

那么数据如何找到对应的分片呢，前面实在已经讲过，如果我们有 3 台机器，常见的分片办法为 hash(IP)%3，个中 3 是机器总数，hash 值为机器 IP，这样每台机器就有自己的分片号。

对付 key，也可以采取同样的办法，找到对应的机器分片号 hash(key)%3，hash 算法有很多，可以用 CRC16(key)，也可以直接取 key 中的字符，通过 ASCII 码转换成数字。

在主从模式下，如果 master 宕机了，从库不能从主库同步数据，主库也不能供应读写功能。

怎么办呢 ？这时就须要引入哨兵机制 ！

哨兵节点是分外的 Redis 做事，不供应读写做事，紧张用来监控 Redis 实例节点。

那么当 master 宕机，哨兵如何实行呢？

哨兵进程会利用 PING 命令检测它自己和主、从库的网络连接情形，用来判断实例的状态，如果哨兵创造主库或从库对 PING 命令的相应超时了，哨兵就会先把它标记为“主不雅观下线”。

那是否一个哨兵判断为“主不雅观下线”，就直接下线 master 呢？

答案肯定是弗成的，须要遵照 “少数服从多数” 原则：有 N/2+1 个实例判断主库“主不雅观下线”，才剖断主库为“客不雅观下线”。

比如上图有 3 个哨兵，有 2 个判断 “主不雅观下线”，那么就标记主库为 “客不雅观下线”。

我们有 5 个从库，须要选取一个最优的从库作为主库，分 2 步：

如果分数同等怎么办 ？ Redis 也有一个策略：ID 号最小的从库得分最高，会当选为新主库。

当 slave 3 选举为新主库后，会关照其它从库和客户端，对外宣告自己是新主库

作者：楼仔原文出处：https://juejin.cn/post/7115001649189355556