共计 7977 个字符，预计需要花费 20 分钟才能阅读完成。
作者：京东批发 王雷
1、Redis 集群计划比拟
• 哨兵模式
在 redis3.0 以前的版本要实现集群个别是借助哨兵 sentinel 工具来监控 master 节点的状态，如果 master 节点异样，则会做主从切换，将某一台 slave 作为 master，哨兵的配置稍微简单，并且性能和高可用性等各方面体现个别。
特地是在主从切换的霎时存在拜访瞬断的状况，而且哨兵模式只有一个主节点对外提供服务，没法反对很高的并发，且单个主节点内存也不宜设置得过大，否则会导致长久化文件过大，影响数据恢复或主从同步的效率。
• 高可用集群模式
redis 集群是一个由多个主从节点群组成的分布式服务器群，它具备复制、高可用和分片个性。Redis 集群不须要 sentinel 哨兵也能实现节点移除和故障转移的性能。
须要将每个节点设置成集群模式，这种集群模式没有核心节点，可程度扩大，据官网文档称能够线性扩大到上万个节点(官网举荐不超过 1000 个节点)。redis 集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。
2、Redis 高可用集群搭建
• redis 集群搭建
redis 集群须要至多三个 master 节点，咱们这里搭建三个 master 节点，并且给每个 master 再搭建一个 slave 节点，总共 6 个 redis 节点，这里用三台机器部署 6 个 redis 实例，每台机器一主一从，搭建集群的步骤如下：
第一步：在第一台机器的 /usr/local 下创立文件夹 redis-cluster，而后在其上面别离创立 2 个文件夾如下（1）mkdir -p /usr/local/redis-cluster（2）mkdir 8001 8004
第二步：把之前的 redis.conf 配置文件 copy 到 8001 下，批改如下内容：（1）daemonize yes（2）port 8001（别离对每个机器的端口号进行设置）（3）pidfile /var/run/redis_8001.pid # 把 pid 过程号写入 pidfile 配置的文件（4）dir /usr/local/redis-cluster/8001/（指定数据文件寄存地位，必须要指定不同的目录地位，不然会失落数据）（5）cluster-enabled yes（启动集群模式）（6）cluster-config-file nodes-8001.conf（集群节点信息文件，这里 800x 最好和 port 对应上）（7）cluster-node-timeout 10000
(8)# bind 127.0.0.1（bind 绑定的是本人机器网卡的 ip，如果有多块网卡能够配多个 ip，代表容许客户端通过机器的哪些网卡 ip 去拜访，内网个别能够不配置 bind，正文掉即可）(9)protected-mode no（敞开保护模式）(10)appendonly yes
如果要设置明码须要减少如下配置：(11)requirepass test (设置 redis 拜访明码)
(12)masterauth test (设置集群节点间拜访明码，跟下面统一)
第三步：把批改后的配置文件，copy 到 8004，批改第 2、3、4、6 项里的端口号，能够用批量替换：:%s/ 源字符串 / 目标字符串 /g
第四步：另外两台机器也须要做下面几步操作，第二台机器用 8002 和 8005，第三台机器用 8003 和 8006
第五步：别离启动 6 个 redis 实例，而后查看是否启动胜利（1）/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/800*/redis.conf（2）ps -ef | grep redis 查看是否启动胜利
第六步：用 redis-cli 创立整个 redis 集群(redis5 以前的版本集群是依附 ruby 脚本 redis-trib.rb 实现)
# 上面命令里的 1 代表为每个创立的主服务器节点创立一个从服务器节点
# 执行这条命令须要确认三台机器之间的 redis 实例要能互相拜访，能够先简略把所有机器防火墙关掉，如果不敞开防火墙则须要关上 redis 服务端口和集群节点 gossip 通信端口 16379(默认是在 redis 端口号上加 1W)
# 敞开防火墙
# systemctl stop firewalld # 长期敞开防火墙
# systemctl disable firewalld # 禁止开机启动
# 留神：上面这条创立集群的命令大家不要间接复制，外面的空格编码可能有问题导致创立集群不胜利（1）/usr/local/redis-5.0.3/src/redis-cli -a test --cluster create --cluster-replicas 1 192.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006
第七步：验证集群：（1）连贯任意一个客户端即可：./redis-cli -c -h -p (- a 拜访服务端明码，- c 示意集群模式，指定 ip 地址和端口号）如：/usr/local/redis-5.0.3/src/redis-cli -a test -c -h 192.168.0.61 -p 800*（2）进行验证：cluster info（查看集群信息）、cluster nodes（查看节点列表）（3）进行数据操作验证（4）敞开集群则须要一一进行敞开，应用命令：/usr/local/redis-5.0.3/src/redis-cli -a test -c -h 192.168.0.60 -p 800* shutdown
3、Java 操作 redis 集群
借助 redis 的 java 客户端 jedis 能够操作以上集群，援用 jedis 版本的 maven 坐标如下：
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
Java 编写拜访 redis 集群的代码非常简单，如下所示：
public class JedisClusterTest {public static void main(String[] args) throws IOException {JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(20);
config.setMaxIdle(10);
config.setMinIdle(5);
Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();
jedisClusterNode.add(new HostAndPort("192.168.0.61", 8001));
jedisClusterNode.add(new HostAndPort("192.168.0.62", 8002));
jedisClusterNode.add(new HostAndPort("192.168.0.63", 8003));
jedisClusterNode.add(new HostAndPort("192.168.0.61", 8004));
jedisClusterNode.add(new HostAndPort("192.168.0.62", 8005));
jedisClusterNode.add(new HostAndPort("192.168.0.63", 8006));
JedisCluster jedisCluster = null;
try {
//connectionTimeout：指的是连贯一个 url 的连贯等待时间
//soTimeout：指的是连贯上一个 url，获取 response 的返回等待时间
jedisCluster = new JedisCluster(jedisClusterNode, 6000, 5000, 10, "zhuge", config);
System.out.println(jedisCluster.set("cluster", "test"));
System.out.println(jedisCluster.get("cluster"));
} catch (Exception e) {e.printStackTrace();
} finally {if (jedisCluster != null)
jedisCluster.close();}
}
}
运行成果如下：OK
test
集群的 Spring Boot 整合 Redis 连贯代码见示例我的项目：redis-sentinel-cluster
1、引入相干依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
springboot 我的项目外围配置：
server:
port: 8080
spring:
redis:
database: 0
timeout: 3000
password: wl
cluster:
nodes: 192.168.0.61:8001,192.168.0.62:8002,192.168.0.63:8003,192.168.0.61:8004,192.168.0.62:8005,192.168.0.63:8006
lettuce:
pool:
max-idle: 50
min-idle: 10
max-active: 100
max-wait: 1000 拜访代码：
@RestController
public class IndexController {private static final Logger logger = LoggerFactory.getLogger(IndexController.class);
@Autowired
private StringRedisTemplate stringRedisTemplate;
@RequestMapping("/test_cluster")
public void testCluster() throws InterruptedException {stringRedisTemplate.opsForValue().set("test", "666");
System.out.println(stringRedisTemplate.opsForValue().get("test"));
}
}
4、Redis 集群原理剖析
Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。
当 Redis Cluster 的客户端来连贯集群时，它也会失去一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，能够间接定位到指标节点。同时因为槽位的信息可能会存在客户端与服务器不统一的状况，还须要纠正机制来实现槽位信息的校验调整。
• 槽位定位算法
Cluster 默认会对 key 值应用 crc16 算法进行 hash 失去一个整数值，而后用这个整数值对 16384 进行取模来失去具体槽位。
HASH_SLOT = CRC16(key) mod 16384
• 跳转重定位
当客户端向一个谬误的节点收回了指令，该节点会发现指令的 key 所在的槽位并不归本人治理，这时它会向客户端发送一个非凡的跳转指令携带指标操作的节点地址，通知客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点下来操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将应用新的槽位映射表。
• Redis 集群节点间的通信机制
redis cluster 节点间采取 gossip 协定进行通信
保护集群的元数据 (集群节点信息，主从角色，节点数量，各节点共享的数据等) 有两种形式：集中式和 gossip
• 集中式
长处在于元数据的更新和读取，时效性十分好，一旦元数据呈现变更立刻就会更新到集中式的存储中，其余节点读取的时候立刻就能够立刻感知到；有余在于所有的元数据的更新压力全副集中在一个中央，可能导致元数据的存储压力。很多中间件都会借助 zookeeper 集中式存储元数据。
• gossip：
gossip 协定蕴含多种音讯，包含 ping，pong，meet，fail 等等。
1）meet：某个节点发送 meet 给新退出的节点，让新节点退出集群中，而后新节点就会开始与其余节点进行通信；
2）ping：每个节点都会频繁给其余节点发送 ping，其中蕴含本人的状态还有本人保护的集群元数据，相互通过 ping 替换元数据(相似本人感知到的集群节点减少和移除，hash slot 信息等)；
3）pong: 对 ping 和 meet 音讯的返回，蕴含本人的状态和其余信息，也能够用于信息播送和更新；
4）fail: 某个节点判断另一个节点 fail 之后，就发送 fail 给其余节点，告诉其余节点，指定的节点宕机了。
gossip 协定的长处在于元数据的更新比拟扩散，不是集中在一个中央，更新申请会陆陆续续，打到所有节点下来更新，有肯定的延时，升高了压力；毛病在于元数据更新有延时可能导致集群的一些操作会有一些滞后。
gossip 通信的 10000 端口
每个节点都有一个专门用于节点间 gossip 通信的端口，就是本人提供服务的端口号 +10000，比方 7001，那么用于节点间通信的就是 17001 端口。每个节点每隔一段时间都会往另外几个节点发送 ping 音讯，同时其余几点接管到 ping 音讯之后返回 pong 音讯。
• 网络抖动
真实世界的机房网络往往并不是惊涛骇浪的，它们常常会产生各种各样的小问题。比方网络抖动就是十分常见的一种景象，忽然之间局部连贯变得不可拜访，而后很快又恢复正常。
为解决这种问题，Redis Cluster 提供了一种选项 cluster-node-timeout，示意当某个节点继续 timeout 的工夫失联时，才能够认定该节点呈现故障，须要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的从新复制)。
Redis 集群选举原理剖析
当 slave 发现自己的 master 变为 FAIL 状态时，便尝试进行 Failover，以期成为新的 master。因为挂掉的 master 可能会有多个 slave，从而存在多个 slave 竞争成为 master 节点的过程，其过程如下：
1）slave 发现自己的 master 变为 FAIL
2）将本人记录的集群 currentEpoch 加 1，并播送 FAILOVER\_AUTH\_REQUEST 信息
3）其余节点收到该信息，只有 master 响应，判断请求者的合法性，并发送 FAILOVER\_AUTH\_ACK，对每一个 epoch 只发送一次 ack
4）尝试 failover 的 slave 收集 master 返回的 FAILOVER\_AUTH\_ACK
5）slave 收到超过半数 master 的 ack 后变成新 Master(这里解释了集群为什么至多须要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举胜利的)
6）slave 播送 Pong 音讯告诉其余集群节点。
从节点并不是在主节点一进入 FAIL 状态就马上尝试发动选举，而是有肯定提早，肯定的提早确保咱们期待 FAIL 状态在集群中流传，slave 如果立刻尝试选举，其它 masters 或者尚未意识到 FAIL 状态，可能会回绝投票
提早计算公式：
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
SLAVE_RANK 示意此 slave 曾经从 master 复制数据的总量的 rank。Rank 越小代表已复制的数据越新。这种形式下，持有最新数据的 slave 将会首先发动选举（实践上）。
集群脑裂数据失落问题
redis 集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区复原，会将其中一个主节点变为从节点，这时会有大量数据失落。
躲避办法能够在 redis 配置里加上参数(这种办法不可能百分百防止数据失落，参考集群 leader 选举机制)：
min-replicas-to-write 1 // 写数据胜利起码同步的 slave 数量，这个数量能够模拟大于半数机制配置，比方集群总共三个节点能够配置 1，加上 leader 就是 2，超过了半数* 留神：这个配置在肯定水平上会影响集群的可用性，比方 slave 要是少于 1 个，这个集群就算 leader 失常也不能提供服务了，须要具体场景衡量抉择。
集群是否残缺能力对外提供服务
当 redis.conf 的配置
cluster-require-full-coverage 为 no 时，示意当负责一个插槽的主库下线且没有相应的从库进行故障复原时，集群依然可用，如果为 yes 则集群不可用。
Redis 集群为什么至多须要三个 master 节点，并且举荐节点数为奇数？
因为新 master 的选举须要大于半数的集群 master 节点批准能力选举胜利，如果只有两个 master 节点，当其中一个挂了，是达不到选举新 master 的条件的。
奇数个 master 节点能够在满足选举该条件的根底上节俭一个节点，比方三个 master 节点和四个 master 节点的集群相比，大家如果都挂了一个 master 节点都能选举新 master 节点，如果都挂了两个 master 节点都没法选举新 master 节点了，所以奇数的 master 节点更多的是从节俭机器资源角度登程说的。
Redis 集群对批量操作命令的反对
对于相似 mset，mget 这样的多个 key 的原生批量操作命令，redis 集群只反对所有 key 落在同一 slot 的状况，如果有多个 key 肯定要用 mset 命令在 redis 集群上操作，则能够在 key 的后面加上{XX}，这样参数数据分片 hash 计算的只会是大括号里的值，这样能确保不同的 key 能落到同一 slot 里去，示例如下：
mset {user1}:1:name zhuge {user1}:1:age 18假如 name 和 age 计算的 hash slot 值不一样，然而这条命令在集群下执行，redis 只会用大括号里的 user1 做 hash slot 计算，所以算进去的 slot 值必定雷同，最初都能落在同一 slot。
哨兵 leader 选举流程
当一个 master 服务器被某 sentinel 视为下线状态后，该 sentinel 会与其余 sentinel 协商选出 sentinel 的 leader 进行故障转移工作。每个发现 master 服务器进入下线的 sentinel 都能够要求其余 sentinel 选本人为 sentinel 的 leader，选举是先到先得。同时每个 sentinel 每次选举都会自增配置纪元(选举周期)，每个纪元中只会抉择一个 sentinel 的 leader。如果所有超过一半的 sentinel 选举某 sentinel 作为 leader。之后该 sentinel 进行故障转移操作，从存活的 slave 中选举出新的 master，这个选举过程跟集群的 master 选举很相似。
哨兵集群只有一个哨兵节点，redis 的主从也能失常运行以及选举 master，如果 master 挂了，那惟一的那个哨兵节点就是哨兵 leader 了，能够失常选举新 master。
不过为了高可用个别都举荐至多部署三个哨兵节点。为什么举荐奇数个哨兵节点原理跟集群奇数个 master 节点相似。