redis集群

Redis集群是一个提供在多个Redis节点间共享数据的程序集

分片：使用redis集群是我们会将存储的数据分散到多台redis机器上

slot槽位映射：

1. 哈希取余分区——机器台数变化，会导致hash取余全部数据重新洗牌
2. 一致性哈希算法分区——哈希环，经过IP地址的哈希函数计算，顺时针确定key的位置；具有容错性；会导致数据倾斜问题
3. 哈希槽分区

哈希槽分区：
哈希槽实质就是一个数组，数组[0,2^14-1]形成hash slot空间
解决均与分配的问题，在数据和节点之间又加了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据
一个集群只能有16384个槽，这些槽会分配给集群中的所有节点，分派策略没有要求。
集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落到对应的槽里。
HASH_SLOT=CRC16(key)mod 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

为什么redis集群的最大槽数是16384个？

1. 如果槽位位65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
2. reids集群的主节点数量基本不可能超过1000；集群主节点越多，心跳包的消息体内携带的数据越多；如果节点过1000个，也会导致网络拥堵。
3. 槽位越少，节点少的情况下，压缩比高，益于传输——redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmapbitmap的填充率slots/N很高的话（N表示节点数），bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低

redis集群不保证强一致性，这意味着在特定的条件下，redis集群可能会丢掉一些被系统收到的写入请求命令

3主3从redis集群配置
找三台真实虚拟机，各自新建：mkdir -p /myredis/cluster
新建6个独立的redis实例服务：
通过redis-cli命令为6台机器构建集群关系：
链接进入6381作为切入点，查看并检验集群状态：info replication ；cluster nodes；cluster info
redis-cli -a 密码 --cluster create --cluster-replicas 1 kafka-broker1:6381 kafka-broker1:6382 kafka-broker2:6383 kafka-broker2:6384 kafka-broker3:6385 kafka-broker3:6386

此时需要使用-c命令连接集群，而不是连接单台redis实例redis-cli -a 密码 -p 6381 -c
查看key的槽位信息：cluster keyslot k1

集群不保证数据的一致性100%OK，一定会有数据丢失情况

集群的主节点的扩容：redis-cli -a 密码 --cluster add-node 真实的主机ip:6387 真实的主机ip:6381
检查槽位分配状况：redis-cli -a 密码 --cluster check 真实的主机ip:6381
从新分配槽位（重新分片）：redis-cli -a 密码 --cluster reshard 真实的主机ip:6381

集群的缩容：
拷贝6388从节点id：618383423cf095417260d981808a45b33d77663e；
从集群中将6388删除：redis-cli -a 密码 --cluster del-node kafka-broker3:6388 618383423cf095417260d981808a45b33d77663e；

redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置在那个槽。集群的每个节点负责一部分的槽。

集群常见命令
cluster nodes
cluster keyslot key
cluster countkeysinslot 槽位id