分片集群结构
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:
1.海量数据存储问题
2.高并发写的问题
使用分片集群可以解决上述问题,分片集群特征:
1.集群中有多个master,每个master保存不同数据
2.每个master都可以有多个slave节点
3.master之间通过ping监测彼此健康状态
4.客户端请求可以访问集群任意节点,最终都会被转发到正确节点
搭建分片集群
1.准备一个新的redis.conf文件:
port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称,不需要我们创建,由redis自己维护
cluster-config-file /tmp/6379/nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /tmp/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 192.168.150.101
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log
2.将这个文件拷贝到每个目录下。
3.修改每个目录下的redis.conf,并做一定的修改。
4.启动相应的redis服务
5.创建集群
虽然服务启动了,但是目前每个服务之间都是独立的,没有任何关联。我们需要执行命令来创建集群,在Redis5.0之前创建集群比较麻烦,5.0之后集群管理命令都集成到了redis-cli中。
redis-cli --cluster create --cluster-replicas n IP IP IP ...
- redis-cli --cluster 或者 ./redis-trib.rb :代表集群操作命令
- create :代表是创建集群
- –replicas 1 或者 --cluster-replicas 1 :指定集群中每个master的副本个数为1,此时 节点总数 ÷ (replicas + 1)得到的就是master的数量。因此节点列表中的前n个就是master,其它节点都是slave节点,随机分配到不同master.
通过命令可以查看集群状态:
redis-cli -p 7001 cluster nodes
散列插槽
Redis会把每一个master节点映射到0~16383共16384个插槽(hash slot)上,查看集群信息时就能看到。
可以简单理解为将16384个插槽分给这些master节点,每个master节点都有一个范围。写到某个插槽上就会写到具体某个master节点上。
数据key不是与节点绑定,而是与插槽绑定。redis会根据key的有效部分计算插槽值,分两种情况:
1.key中包含"{}",且“{}”中至少包含1个字符,“{}”中的部分是有效部分
2.key中不包含“{}”,整个key都是有效部分
例如:key是num,那么就根据num计算,如果是{itcast}num,则根据itcast计算。计算方式是利用CRC16算法得到一个hash值,然后对16384取余,得到的结果就是slot值。
Redis如何判断某个key应该在哪个实例?
将16384个插槽分配到不同的实例
根据key的有效部分计算哈希值,对16384取余
余数作为插槽,寻找插槽所在实例即可
如何将同一类数据固定的保存在同一个Redis实例?
这一类数据使用相同的有效部分,例如key都以{typeId}为前缀
集群伸缩
集群伸缩也就是往集群中添加master节点和删除master节点.
redis-cli --cluster提供了很多操作集群的命令,可以通过下面方式查看:
添加后记得分配插槽,将某个节点的插槽分给这个节点多少个,相应的数据也移(拷贝)到这个节点上。
故障转移
当集群中有一个master宕机会发生什么呢?
- 首先是该实例与其它实例失去连接
- 然后是疑似宕机:
- 最后是确定下线,自动提升一个slave为新的master:
利用cluster failover
命令可以手动让集群中的某个master宕机,切换到执行cluster failover命令的这个slave节点,实现无感知的数据迁移。其流程如下:
手动的Failover支持三种不同模式:
1.缺省:默认的流程,如图1~6歩
2.force:省略了对offset的一致性校验
3.takeover:直接执行第5歩,忽略数据一致性、忽略master状态和其它master的意见