重庆建设银行网站首页,如何做彩票网站,小程序开发公司哪家好如何选择,博物馆网站建设情况说明哨兵机制中总结到#xff0c;它并不能解决存储容量不够的问题#xff0c;但是集群能。 广义的集群#xff1a;只要有多个机器#xff0c;构成了分布式系统#xff0c;都可以称之为一个“集群”#xff0c;例如主从结构中的哨兵模式。 狭义的集群#xff1a;redis 提供的…哨兵机制中总结到它并不能解决存储容量不够的问题但是集群能。 广义的集群只要有多个机器构成了分布式系统都可以称之为一个“集群”例如主从结构中的哨兵模式。 狭义的集群redis 提供的集群模式该模式主要是解决存储空间不够的问题拓展存储空间
集群的基本原理
在哨兵模式中本质上还是 redis 主从节点存储数据就要求一个主节点/从节点存储整个数据的“全集”当数据量很大的时候就需要很大的内存这时候把数据全保存在一台机器上就不太合适。
所以就需要引入多台机器每台机器存储一部分数据。
但是并不是多引入机器就够了每一台机器还要有对应的从节点主要是为了在主节点挂了的情况下进行数据备份。 怎么把数据分成多份分片方法
哈希求余 设有 N 个分片使用[0, N - 1]这样的序号进行编号 针对某个给定的 key先计算 hash 值再把得到的结果 % N得到的结果即为分片编号 但是这样的方法在数据量持续增大大到需要进一步增加机器的时候或者缩容的时候开销比较大。
因为机器的数量增多就意味着 N 的大小变化了求出的 hash 值也会变化这时需要将原来的分片中的数据搬运到新的位置。
而且并不只是从一台数据搬运到另一台数据还需要重新进行数据的备份。
所以为了避免这么大的开销往往不能直接在生产环境上操作只能通过“替换”的方式实现也就是不改变机器中存储的数据而改变各台机器的主从关系。但这样的做法需要依赖更多的机器成本更高操作步骤复杂。
一致性哈希算法
为了降低上述的搬运开销能够更高效扩容业界提出来“一致性哈希算法”。
key 映射到分片序号的过程不再是简单求余而是改为以下过程 把 0 - 2^32 - 1 这个数据空间映射到一个圆环上数据按照顺时针方向增长 2. 假设当前存在三个分片就把分片放到圆环的某个位置上 3. 假定有一个 key计算得到 hash 值 H那么这个 key 就从 H 所在位置顺时针往下找找到的第一个分片即为该 key 所从属的分片 这就相当于N 个分片的位置把整个圆环分成了 N 个管辖区间key 的 hash 值落在某个区间内就归对应区间管理。 基于这种规则连续的值不再是交替地出现在每一个分区中而是连续的值处于一个分区再增容或者缩容的时候需要数据搬运的概率就大大降低了需要搬运的数据也减少了。
但是虽然搬运成本低了但这几个分片上的数据量可能会不再均匀数据倾斜。
哈希槽分区算法Redis真正采用的方法
为了解决上述问题搬运成本高和数据分配不均匀Redis cluster 引入了哈希槽hash slots算法。 hash_slot clc16(key) % 16384 其中 clc16 也是一种 hash 算法16384 是 16 * 1024也就是 2^14。
相当于把整个哈希值映射到 16384 个槽位上也就是 [0, 16384]。
然后再把这些槽位比较均匀地分配给每个分片每个分片的节点都需要记录自己持有哪些分片。 假设当前有三个分片一种可能的分配方式 0 号分片[0, 5461]共 5462 个槽位 1 号分片[5462, 10923]共 5462 个槽位 2 号分片[10924, 16383]共 5460 个槽位
这里的分片规则是很灵活的每个分片持有的槽位也不一定连续。
每个分片的节点使用位图来表示自己持有哪些槽位对于 16384 个槽位来说需要 2048 个字节2KB大小的内存空间表示。
如果需要进行扩容就可以针对原有的槽位进行重新分配。
一种可能的分配方式 0 号分片[0, 4095]共 4096 个槽位 1 号分片[5462, 9557]共 4096 个槽位 2 号分片[10924, 15019]共 4096 个槽位 3 号分片[4096, 5461] [9558, 10923] [15020, 16383]共 4096个槽位
在实际使用 Redis 集群分片的时候不需要手动指定哪些槽位分配给某个分片只需要告诉某个分片应该持有多少个槽位即可Redis 会自动完成后续的槽位分配以及对应的 key 搬运的工作。
Redis 集群最多有 16384 个分片吗
不是的如果集群有 16384 个分片就意味着每个分片上只有一个槽位。key 值需要先映射到槽位再映射到分片。如果每个分片包含的槽位比较多并且槽位个数相当就可以认为包含的 key 的数量相当但如果每个分片的槽位很少就不能直观地反应出 key 的数量因为经过 hash 映射后具体到哪个分片的随机性比较大。
而且如果分片个数达到 1.6w 这么大所需要的主机数可能会达到 4w 以上集群规模太大可用性就会很难保证出故障的概率会变大。
实际上Redis 的作者建议集群分片数不应该超过 1000.
为什么是 16384 个槽位 节点之间通过心跳包通信心跳包中包含了该节点持有哪些 slots。这个是使用位图的结构表示的表示 16384(16k)个 slots需要的位图大小是 2KB。如果给定的 slots 数更多了则需要消耗更多的空间8KB来表示。这样的空间虽然对于内存来说不算什么但是在频繁的网络心跳包中是一个不小的开销。 另一方面Redis 集群一般不建议超过 1000 个分片。所以 16K 对于最大 1000 个分片来说是足够用的同时也会使对应的槽位配置位图体积不至于很大。
故障处理
故障判定
集群中的所有节点都会周期性的使用心跳包进行通信。 节点 A 给节点 B 发送 ping 包B 就会给 A 返回一个 pong 包。ping 和 pong 处理 message type 属性之外其他部分都是一样的。这里包含了集群的配置信息该节点的 id该节点从属于哪个分片是主节点还是从节点从属于谁持有哪些 slots 的位图...。 每个节点每秒钟都会给一些随机的节点发起 ping 包而不是全发一遍。这样设定是为了避免在节点很多的时候心跳包也非常多比如有 9 个节点如果全发就是 9 * 8 有 72 组心跳了而且这是按照 N^2 这样的级别增长的。 当节点 A 给节点 B 发起 ping 包B 不能如期回应的时候此时 A 就会尝试重置和 B 的 TCP 连接看能否连接成功。如果仍然连接失败A 就会把 B 设为 PFAIL 状态相当于主观下线。 A 判定 B 为 FAIL 之后会通过 redis 内置的 Gossip 协议和其他节点进行沟通向其他节点确认 B 的状态每个节点都会维护一个自己的“下线列表”由于视角不同每个节点的下线列表也不一定相同。 此时 A 发现其他很多节点也认为 B 为 FAIL并且数目超过总集群个数的一半那么 A 就会把 B 标记成 FAIL相当于客观下线并把这个消息同步给其他节点其他节点收到之后也会把 B 标记成 FAIL。
至此B 就彻底被判定为故障节点了。
某个或某些节点宕机有时候会引起整个集群都宕机成为 FAIL 状态。
以下三种情况会出现集群宕机 某个分片所有的主节点和从节点都挂了。 某个分片主节点挂了但没有从节点。 超过一半的 master 节点挂了。
核心原则是保证每个 slots 都能正常工作存取数据
故障迁移
上述例子中B 故障并且 A 把 B FAIL 的消息告知集群中的其他节点。 如果 B 是从节点则不需要进行故障迁移。 如果 B 是主节点则会由 B 的从节点例如 C 和 D触发故障迁移。
所谓的故障迁移就是把从节点提拔成主节点继续给整个 redis 集群提供支持。
具体流程如下 从节点判定自己是否具有参选资格。如果从节点和主节点已经太久没有通信此时认为从节点中的数据和主节点相差太大了时间超过阈值就失去竞选资格。 具有资格的结点例如 C 和 D就会先休眠一段时间。休眠时间 500ms 基础时间 [0, 500ms] 随机时间 排名 * 1000ms。offset 的值越大则排名越靠前。 例如 C 的休眠时间到了C 就会给其他所有集群中的节点进行拉票操作。但只有主节点才有投票资格。 主节点就会把自己的票投给 C每个主节点只有 1 票。当 C 收到的票数超过主节点数目的一半C 就会晋升成主节点C 自己负责执行 slaveof no one并让 D 执行 slaveof C。 同时C 还会把自己成为主节点的消息同步给其他集群的节点大家也都会更新自己保存的集群结构信息。
上述选举的过程称为 Raft 算法是一种在分布式系统中广泛使用的算法。
在随机休眠时间的加持下基本上就是谁先唤醒谁就能竞选成功。
