Redis 单机不能保证高可用 从主从模型到哨兵的演变

下载并且编译安装

配置主从的conf

创建一个redis的主从文件夹

mkdir redis_master_slave

在redis_master_slave文件夹内创建三个文件7001、7002、7003

mkdir -p 7001/conf 7002/conf 7003/conf

将redis中的配置文件redis.conf复制到上面各个conf中去

在700相关文件夹中的redis.conf中的配置进行修改

# 端口7001,7002,7003
port  7001                                              
# bind 0.0.0.0，这样是允许任何机器都可以访问该服务器 
# 默认ip为127.0.0.1 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口，否则无法主从
bind 主机ip   
# redis后台运行                                    
daemonize    yes                     
# pidfile文件对应6379,6380,6381          
pidfile  /var/run/redis_7000.pid     
# aof日志开启  有需要就开启，它会每次写操作都记    
appendonly  yes              
# 和dir 有关系             
logfile "文件名"                   
# 数据存储路径
dir "/usr/local/software/redis_master_slave/7001/data"   
# 在7002,7003里面配置，作为从                    
slaveof 绑定ip 7001    
# 其他配置一句需求做响应的设置
# 本机redis密码 如果哨兵中配置，那么主从都配置
requirepass 123456 
# 主机redis密码 如果哨兵中配置，那么主从都配置
masterauth "123456" 

启动redis

#!/bin/sh
​
for ((i=1;i<4;i++))
do
 redis-server ./700$i/conf/redis.conf
done

哨兵机制简介

哨兵机制的消息介绍

配置哨兵

哨兵的 conf文件一般都在redis的当前解压目录下

在redis_master_slave 目录下创建 mkdir -p sentinel/conf mkdir -p sentinel/log

在redis的根目录下mv sentinel.conf ../sentinel/conf

# 端口
port 26379
# 工作路径，注意路径不要和主重复
dir "/usr/local/software/redis_master_slave/sentinel/log"
# 指明日志文件名
logfile "./sentinel.log"
​
sentinel myid bea48b4599058ed53d7b43b1b13c886bcbda232c
# 绑定主机
bind 172.16.93.101
# 守护进程模式
daemonize yes
​
sentinel deny-scripts-reconfig yes
# 哨兵监控的master，主从配置一样，这里只用输入redis主节点的ip/port和法定人数 
# 这个1代表，当集群中有2个sentinel认为master挂了时，才能真正认为该master已经不可用了
sentinel monitor mymaster 127.0.0.1 7001 1
​
sentinel config-epoch mymaster 1
​
sentinel leader-epoch mymaster 1
# 密码  没有可不设置
# sentinel auth-pass mymaster 123456
​
# Generated by CONFIG REWRITE 下面三个配置是自动生成的
sentinel known-slave mymaster 127.0.0.1 7001
sentinel known-slave mymaster 127.0.0.1 7002
sentinel current-epoch 1

启动哨兵

redis-sentinel /usr/local/software/redis_master_slave/sentinel/conf

哨兵机制起到的作用

sentinel架构的主要作用是解决主从模式下主节点的故障转移工作的。这里如果主节点因为故障下线，那么某个sentinel节点发送检测消息给主节点时，如果在指定时间内收不到回复，那么该sentinel就会主观的判断该主节点已经下线，那么其会发送消息给其余的sentinel节点，询问其是否“认为”该主节点已下线，其余的sentinel收到消息后也会发送检测消息给主节点，如果其认为该主节点已经下线，那么其会回复向其询问的sentinel节点，告知其也认为主节点已经下线，当该sentinel节点最先收到超过指定数目（配置文件中配置的数目和当前sentinel节点集合数的一半，这里两个数目的较大值）的sentinel节点回复说当前主节点已下线，那么其就会对主节点进行故障转移工作，故障转移的基本思路是在从节点中选取某个从节点向其发送slaveof no one（假设选取的从节点为127.0.0.1:6380），使其称为独立的节点（也就是新的主节点），然后sentinel向其余的从节点发送slaveof 127.0.0.1 6380命令使它们重新成为新的主节点的从节点。重新分配之后sentinel节点集合还会继续监控已经下线的主节点（假设为127.0.0.1:6379），如果其重新上线，那么sentinel会向其发送slaveof命令，使其成为新的主机点的从节点，如此故障转移工作完成

优点及解决问题

• 同一个Master可以同步多个Slaves
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构
• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求
• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据
• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高
• Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

❗️❗️❗️注意点

在实现redis客户端API工具类时，出现的问题

使用StringRedisSerializer序列化方式，**不能在string类型中存储对象等非string信息

使用JdkSerializationRedisSerializer序列化方式，不能对整数、浮点进行incr自增操作

使用GenericJackson2JsonRedisSerializer序列化方式，存储的json串信息较比byte方式性能较慢