redis之集群

一、问题

1.1 redis 集群为什么槽位选择16384

在 Redis 集群中，Redis 根据公式 HASH_SLOT=CRC16(key) mod 16384 ，来确定客户端的 key 映射到哪个分片上，然后 Redis 会去相应节点进行操作。然而，CRC16 算法最多可产生 65535 个槽位，但是 Redis 的取模 是16384 ，主要基于如下两个原因：

①Redis 节点在发送心跳数据包时需要将所有槽都放入到这个心跳包里，如果采用 16384 个插槽，占用空间为 2KB（16384/8）;如果采用 65536 个插槽，占空间 8KB （65536/8）。8KB 的心跳数据有点儿大。
16384b/8/1024=2KB
②Redis Cluster 不太可能扩展到超过 1000 个节点，太多会导致网络拥堵。选择 16384 ，照样可以确保每个主节点都有足够的槽。
所以，选择 16384 既可以保证集群中每个节点都有足够的槽，又能保证心跳数据包不会过大。

1.2 redis集群不保证强一致性

当一个主机宕机，并且其从机还没有上位时，可能会出现写丢失。

二、实例演示

2.1 配置集群

首先给每个服务器添加上开启集群的配置，接着开启redis主机实例，

之后为机器构建集群关系

自动分配主从节点。

添加key时，防止路由失效，比如当前节点只能写0-4096，但是你的key映射到了4097，则会报错，所以我们要添加一个参数 -c 保证连接，即使当前槽位不在该主机，也不会报错，会重定位到另一个主机。

2.2 主机宕机

当一个主机宕机之后，其从机会上位，如果宕机的主机又启动了，那么它会自动变为从机。如果想要恢复和原来关系一样，可以采用

2.3 扩容

扩容 首先将扩容的机器添加上集群开启配置，之后将机器添加到原始集群上，
redis-cli --cluster add-node <new-node-ip>:<new-node-port> <existing-node-ip>:<existing-node-port>

分配槽位
redis-cli --cluster reshard <existing-node-ip>:<existing-node-port>
给新的主节点 添加从节点(同时把该节点加入汲集群)

2.4 缩容

缩容
删除当前主节点对应的从节点
将要删除的主节点的槽位清空，进行重新分配
删除主节点

三、简介集群

主从复制时，当主节点宕机了，从节点并不能自动升级为主节点，所以出现了哨兵，哨兵可以帮助我们选择一个从节点上位，但是哨兵有一个缺点就是它只有一个主结点，扩容缩容不方便，主节点压力大，集群可以让我们有多个主节点和从节点。

3.1 什么是槽slot

redis集群槽有16384个哈希槽，每个key通过CRC16校验后来决定放入哪个槽，集群的每个结点负责一部分哈希槽。
也就是在数据放入到结点之前加了一步槽的概念，先确定槽，把数据放到对应槽上，在确定放到哪个节点上。当我们后续槽进行重新分配时，上边的数据也会跟着移动。

3.2 什么是分片

分片其实就是看有几个主节点，一整个集群可以进行分片，每个分片确定一部分哈希槽。

3.2.1 分片和槽的优势

可以很容易的进行添加或者删除节点，添加或者删除节点，移动槽位分配信息时，并不会停止服务，捕获造成集群成不可用的状态。就是即使删除了一个节点，我们可以把它的槽位分配出去，该集群仍是可用的。

3.3 槽位映射算法

我们的槽位信息到底对应到哪个机器上？

3.3.1哈希取余分区算法

hash(key)/节点数。
该算法简单，但是它的缺点很大，就是比如扩容或者缩容时，我们的节点就会有变化，会造成我们的槽位分配信息大片混乱。

3.3.2 一致性哈希算法分区

①一致性哈希环

②每个节点通过映射 映射到哈希环上

③key落到服务器的落键规则

优点： 容错性和扩容性，就是即使节点变化，扩容或者缩容时，并不会全部槽位映射混乱，只会影响一部分数据。

缺点： 数据倾斜问题
可能会导致一个主机分配的槽位太多，但是其他主机太少。不能自动分配。

3.3.3 哈希槽分区

3.3 常用命令

3.3.1 是否对外提供命令

如果一个主节点挂了，不能对外提供服务，如果是yes，则不能对外提供服务，如果是no，则可以对外提供服务。

cluster-require-full-coverage

3.3.2 槽位是否被占用

0代表没有被占用，1代表已经被占用
CLUSTER COUNTKEYSINSLOT 槽位编号

3.3.3 当前key分配到哪个槽位

CLUSTER KEYSOLT KEY

3.3.4 集群结点信息

CLUSTER NODES