上篇主要搭建了哨兵模式,该模式主要是用来监控master节点,若出现故障会进行主从切换,如果在主从切换的瞬间存在访问快速断开的情况,这些时间内没法提供写服务,且单个节点内存也不宜设置过大,否则导致持久化文件过大,影响数据恢复或主从同步效率。
所以可以使用集群模式弥补这些问题。
redis集群是由多个主从节点组成的分布式集群,具有复制、高可用和分片的特性。它不需要哨兵也能完成节点的故障转移。该集群模式没有中心节点,可水平扩展。
当然我为了简单一些,我把每个master下,只有一个savle,还可以在加一个比较完美。当然上面的图只是参考,具体创建出来可能会不一样,但是一定是三主三从。
集群搭建
1.准备节点:
现在是6个redis实例,我把分别放到3台机器当中,130机器中两个redis实例,131中两个实例,132中两个实例。
2.修改配置文件
cluster-enabled yes 启动集群模式
cluster-config-file node-6379.conf
cluster-node-timeout 10000
requirepass zz redis访问密码
masterauth zz 设置集群节点间访问密码
同样几台机器按着这个修改,主要是端口号
3.用redis-cli创建整个redis集群
redis-cli -a zz --cluster create --cluster-replicas 1 192.168.0.130:6379 192.168.0.131:6379 192.168.0.132:6379 192.168.0.130:6380 192.168.0.131:6380 192.168.0.132:6380
这个顺序 可能会影响集群的主从节点关系。
4.验证集群
连接任意客户端
redis-cli -a zz -c -h 192.168.0.130 -p 63*
进行验证:cluster info (查看集群信息) cluster nodes(查看节点列表)
关闭集群:
redis-cli -a zz -c -h 192.168.0.130 -p 63* shutdown
集群原理分析
redis cluster将所有数据划分为16384个槽位,每个节点负责其中的一部分,槽位的信息位于每个节点中。
当redis cluster的客户端来连接集群时,它也会得到一份集群槽位配置信息并缓存在客户端本地。当客户端要查找某个key时,直接定位到目标节点(类似于hashmap的key定位)。有可能槽位的信息会存在客户端与服务端不一致的情况,还需要纠正机制来重新校验调整(跳转重定向)。
集群是否完整才能对外提供服务
cluster-require-full-coverage no 表示当负责一个插槽的主节点下线且没有相应的从节点进行故障恢复时,集群可用,若为yes,则不可用。
意思就是说一个master挂了,若它下从节点能不能成为主节点,且该参数为no 时,集群可用。