Redis集群(caluster)
Redis集群是一个提供在多个Redis节点间共享数据的程序集
1. Redis集群的作用:
Redis 集群是 Redis 的分布式实现，在设计中按重要性顺序具有以下目标：
- 高性能和线性可扩展性，多达 1000 个节点。没有代理，使用异步复制，并且不对值执行合并操作。
- 可接受的写入安全程度：系统尝试（以最大努力）保留来自与大多数主节点连接的客户端的所有写入。通常有一些小窗口，其中确认的写入可能会丢失。当客户端位于少数分区中时，丢失已确认写入的 Windows 会更大。
- 可用性：Redis 集群能够在大多数主节点可访问的分区中幸存下来，并且对于不再可访问的每个主节点，至少有一个可访问的副本。此外，使用副本迁移，不再由任何副本复制的主节点将从多个副本覆盖的主节点接收一个。
本文档中描述的内容在 Redis 3.0 或更高版本中实现
2. redis集群的数据分片
redis集群没有使用一致性hash,而是引入了哈希槽的概念
redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,进群的每个节点负责一部分hash槽
举个例子,比如集群有三个节点,那么:
也就是说,某个key通过CRC16算法,算出的值是9766,
那么它就会被第二个节点储存
3. 分片的好处
这种使用哈希槽的结构很容易添加或者删除节点
比如我们想要添加节点D,我需要从节点A,B,C中得部分槽到D上,如果我想要移除节点A,需要将A中的槽移动到B,C上
由于从一个节点将哈希槽移动到另一个节点,并不会停止服务,所以无论添加或删除或修改某个节点的哈希槽数量都不会造成集群不可用的状态
4. 为什么哈希槽的数量是16384
==
5.-c 命令
启动redis服务器-c命令,会自动将键值存入对应哈希槽的节点里面
cluster keyslot k1 //查询c1在那个集群里面
6. redis集群的主从切换
6381主机宕机了,对应的从机6384是否上位?
我们发现6384成功上位,成为master
6381如果重连,是否会上位?
我们发现和哨兵模式一样,6381成为6384的从机!!!
如何回调主从关系?
CLUSTER FAILOVER
执行命令后,我们惊奇的发现:
6381重新变回主机身份
6384成为从机
7. 集群扩容
增加集群6387–6388
新增加的集群还没有槽位:
重新分配槽号:
服务器会询问你移动多少槽位,我们默认是16384除以N
并把6387的node id 复制过去:
相当于用6387接收4096个槽位
我们重新执行命令,发现:
槽位确实分配过去了!!!
并且发现6387的槽位是前三家匀过去的!!!
为6387添加从机:
总结流程:
6387通过6381介绍加入集群
redis-cli -a 111111 --cluster add-node 127.0.0.1 6387 127.0.0.1 6381
分配哈希槽给6387
redis-cli -a 111111 --cluster reshard 127.0.0.1 6387
4096
输入6387的node id
给6387加入从机6388
redis-cli -a 111111 --cluster add-node 127.0.0.1 6388 127.0.0.1 6387 --cluster-slave --cluster-master-id 新主机节点的ID
文字描述:
首先通过已有的主机节点来使得新的主机节点加入集群,然后通过reshard关键字分配给新主机节点哈希槽
输入分配哈希槽的数量和新主机节点ID得到分配
最后通过--cluster add-node 命令给新主机节点添加从机节点
8. 集群缩容
第一步,删除从节点6388:
redis-cli -a 111111 --cluster del-node 127.0.0.1 6388 6388的节点ID
第二步,将6387的槽号清空,重新分配,本例全部分配给6381:
redis-cli -a 111111 --cluster reshard 127.0.0.1 6381
你想要移动多少个槽位: 4096
接收槽位的节点ID: 6381的节点ID
Source ID : 6387的节点ID
done
==
==
==
另外我们发现,6387失去哈希槽后自动降级为从机节点
并且跟着6381混
第三步:删除6387
redis-cli -a 111111 --cluster del-node 127.0.0.1 6387 6387节点ID
9. redis集群总结
==
==
