Redis主从集群搭建及主从复制原理解析
前言上篇文章我解析了如何搭建主从集群，以及主从复制原理分析；本篇文章继续对集群继续沉入，以及常见运行时的检测工具，及哨兵机制原理的解析，以及遇到常见问题的处理
Redis客户端及监控集群Redis在集群中数据同步流程
集成在spring中，实现就很简单，只要连接主节点即可，而对于从节点，是会自动发现的。并且在设置 ReadFrom.SLAVE_PREFERRED 时，会自动选择读写的情况
@Configuration
@Profile("replication-rw") // 主从 - 读写分离模式
public class ReplicationRWRedisAppConfig {
@Value("${redis_host}")
private String redisHost;
@Value("${redis_port}")
private int redisPort;
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
System.out.println("使用读写分离版本");
LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
.readFrom(ReadFrom.SLAVE_PREFERRED)
.build();
// master:192.168.1.128 slave:192.168.1.145
// 默认slave只能进行读取，不能写入
// 如果你的应用程序需要往redis写数据，建议连接master
RedisStandaloneConfiguration serverConfig = new RedisStandaloneConfiguration(redisHost, redisPort);
return new LettuceConnectionFactory(serverConfig, clientConfig);
}
}
Monitor命令
monitor 是一个调试命令，返回服务器处理的每个命令。对于发现程序的错误非常有用。
出于安全考虑，某些特殊管理命令ConFIG 不会记录到MONITOR输出
运行一个MONITOR命令能够降低50%的吞吐量，运行多个MONITOR命令 降低的吞吐量更多。
可以将所有的命令都监听上。
这个命令只适用于在测试环境上，不适合生产环境上，上产环境上是非常消耗性能的。
Info 命令
INFO命令以一种易于理解和阅读的格式，返回关于Redis服务器的各种信息和统计数值。
可以通过section 返回部分信息，如果没有使用任何参数时，默认为default。
图形化监控工具 - RedisLive
这个工具git 地址 为：GitHub - nkrode/重新使用：可视化您的重新出现实例，分析查询模式和峰值。
可视化您的重新出现实例，分析查询模式和峰值。
作为一款开源的 Redis 图形化监控工具，RedisLive 提供对 Redis 实例的内存使用情况，接收的客户端命令，接收的请求数量以及键进行监控。RedisLive 的工作原理基于 Redis 的 INFO 和 MonITOR 命令，通过向 Redis 实例发送 INFO 和 MonITOR 命令来获取 Redis 实例当前的运行数据。
安装 则直接使用git 命令
git clone https://github.com/kumarnitin/RedisLive.git哨兵机制(Sentinel)
Redis Sentinel是一个分布式系统，为Redis提供高可用性解决方案。可以在一个架构中运行多个 Sentinel 进程(progress)， 这些进程使用流言协议(gossip protocols)来 接收关于主服务器是否下线的信息， 并使用投票协议(agreement protocols)来决定是否执行自动故 障迁移， 以及选择哪个从服务器作为新的主服务器。
如何配置一个哨兵高可用搭建，可以按照下面的文档进行搭建
redis哨兵高可用搭建 提取码: mth1
# 云服务器要注意ip要写对，端口要开放 # 虚拟机要注意防火墙要关闭 systemctl stop firewalld.service
# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的 # sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态 # 绑定IP bind 0.0.0.0 # 后台运行 daemonize yes # 默认yes，没指定密码或者指定IP的情况下，外网无法访问 protected-mode no # 哨兵的端口，客户端通过这个端口来发现redis port 26380 # 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信 # sentinel announce-ip # 临时文件夹 dir /tmp # 日志 logfile "/usr/local/redis/logs/sentinel-26380.log" # sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡 sentinel monitor mymaster 192.168.100.241 6380 2 # 发送心跳PING来确认master是否存活 # 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了 sentinel down-after-milliseconds mymaster 1000 # 如果在该时间（ms）内未能完成failover操作，则认为该failover失败 sentinel failover-timeout mymaster 3000 # 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长 sentinel parallel-syncs mymaster 1
启动 直接使用 /usr/local/redis/bin/redis-server /usr/local/redis/conf/sentinel-26380.conf --sentinel 启动既可
在spring中配置
@Configuration
@Profile("sentinel")
public class SentinelRedisConfig {
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
System.out.println("使用哨兵版本");
RedisSentinelConfiguration sentinelConfig = new RedisSentinelConfiguration()
.master("mymaster")
// 哨兵地址
.sentinel("192.168.100.16", 26379)
.sentinel("192.168.100.8", 26380)
.sentinel("192.168.100.8", 26381);
return new LettuceConnectionFactory(sentinelConfig);
}
}
这个名字和配置文件中的名字对应就好
哨兵(Sentinel)核心机制- 简化客户端的配置选择，客户端只用配置好哨兵的地址即可，无需连接主节点
-
引入哨兵机制，哨兵通过ping去感知监控、通知、自动故障转移、配置提供。
-
主节点故障 ，选则到新的主节点， slave of no one 将新的主节点选择，并将从节点的主节点重新设置。
-
哨兵中有主观下线， 和客观下线，当一台哨兵认为下线时是主观下线，只有大多数哨兵认为下线则认为是客观下线，真的下线，可以配置参数去设置
服务发现和健康检查流程
故障切换流程
哨兵常见的命令
直接通过sentilnel sentinels 进行查看哨兵的端口号等等
利用哨兵的命令 使用sentinel slaves mymaster就可以查看从节点信息
在哨兵或者redis服务中，由于网络中断有可能出现分布式的情况下出现脑裂的情况，因为有大多数的机制，因此并不存在这个问题，如果出现网络隔断，没有达到大多数的情况，则会不能使用，当重新连接上时，在根据offset进行数据更新
哨兵7大核心概念1. 哨兵如何知道Redis主从信息（自动发现机制）
哨兵配置文件中，保存着主从集群中master的信息，可以通过info命令，进行主从信息自动发现。配置文件中保存着 master的 ip和端口号。# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡 sentinel monitor mymaster 192.168.100.241 6380 2这里 在master 中通过 info replication 可以找到从节点
2. 什么是master主观下线
主观下线 ：单个哨兵自身认为redis实例已经不能提供服务 检测机制 ：哨兵向redis发送ping请求，+PONG、-LOADING、 -MASTERDOWN这三种情况视为正常，其他回复均 视为无效。 对应配置文件的配置项： sentinel down-after-milliseconds mymaster 1000# 发送心跳PING来确认master是否存活 # 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了 sentinel down-after-milliseconds mymaster 1000
3. 什么是客观下线
客观下线：一定数量的哨兵任务master已经下线。
检测机制 ：当哨兵主观认为master下线后，则会通过 SENTINEL is-master-down-by-addr命令 询问其他哨兵 是否认为master已经下线，如果达成共识（ 达到quorum个数 ），就会认为master节点客观下线，开始故障转移流程# 发送心跳PING来确认master是否存活 # 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了 sentinel down-after-milliseconds mymaster 1000
4. 哨兵之间如何通信（哨兵之间的自动发现）
如果是多哨兵模式，哨兵节点之间也是可以相互感知的
如下是在Redis主从复制的基础上，依次启用三个哨兵节点的后，sentinel.cnf的变化情况
可以发现，当启用了三个哨兵节点之后，sentinel.cnf配置文件会被自动重写，主要有一下几点，如
1，增加了一个sentinel myid （标识哨兵节点的唯一性）
2，自动追加哨兵节点本身的信息（这样哨兵节点之间就会相互自动发现），以及redis数据服务的slave的信息
3，自动移除主节点的密码
4，dir 的相对路径被修改为绝对路径
总的来说 通过发布订阅 pub/sub 通道去监听 通过2000的偏移量端口，进行通信。
5. 哪个哨兵负责故障转移？(哨兵领导选举机制)
1.每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其他哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
2.当其他哨兵收到此命令时，可以同意或者拒绝它成为领导者；
3.如果哨兵3发现自己在选举的票数大于等于哨兵的个数/2+1时，将会成为领导者，如果没有超过，继续选举。。。。
基于 Raft算法实现的选举机制 ，流程简述如下： 1. 拉票阶段：每个哨兵节点希望自己成为领导者； 2. sentinel节点收到拉票命令后，如果没有收到或同意过其他sentinel节点的请求，就同意该sentinel 节点的请求（每个sentinel只持有一个同意票数）； 3. 如果sentinel节点发现自己的票数已经超过一半的数值，那么它将成为领导者，去执行故障转移； 4. 投票结束后，如果超过failover-timeout的时间内，没进行实际的故障转移操作，则重新拉票选举。
6. slave选举机制
slave的选举机制有个大多数机制，包括哨兵自己的选择，也遵从raft算法，这个比zookeeper中的paxos算法更简单一点
raft算法学习
slave 节点状态 ，非 S_DOWN,O_DOWN，DISConNECTED 判断规则：(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state SENTINEL slaves mymaster slave 节点状态 ，非 S_DOWN,O_DOWN，DISConNECTED 判断规则：(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state SENTINEL slaves mymaster 优先级 redis.conf中的一个配置项： slave-priority 值越小，优先级越高 数据同步情况 Replication offset processed 最小的run id run id 比较方案： 字典顺序， ASCII码7. 最终主从切换的过程
针对即将成为master的slave节点，将其撤出主从集群 自动执行：slaveof NO ONE 针对其他slave节点，使它们成为新master的从属 自动执行：slaveof new_master_host new_master_port
