Docker部署Redis主从和哨兵
1. 主从复制概述
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
主从复制的作用
主从复制的作用主要包括：
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础
2. 实验环境
本人采用虚拟机VMware内装centos7版本的Linux系统,redis部署都采用docker容器技术
| 主机说明 | 主机IP | 端口 | 哨兵端口 |
| master | 192.168.222.157 | 6379 | 26379 |
| slave1 | 192.168.222.157 | 6380 | 26380 |
| slave2 | 192.168.222.157 | 6381 | 26381 |
3. 架构
典型的哨兵架构图如下所示：
它由两部分组成，哨兵节点和数据节点：
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
- 数据节点：主节点和从节点都是数据节点。
4. 部署主从
目的：1个主节点、2个从节点和3个哨兵节点
4.1 准备
所有主从服务器上操作
1.下载redis镜像
# 下载redis docker pull redis
2.在/root目录下创建6个redis目录分别存放6个redis容器的配置
3.每个redis目录下创建conf文件夹存放redis配置文件
4.下载redis配置文件
wget http://download.redis.io/redis-stable/redis.conf
5.配置master redis.conf文件（只需修改红色的配置即可）
protected-mode no port 6379 daemonize no
dir /opt/redis/data/ 数据存储目录
#requirepass xd@2020 需要配置密码可加
#masterauth xd@2020 需要配置密码可加
6.配置slave redis.conf文件（只需修改红色的配置即可）（两台slave配置一样，只是换一下port 6380和6381）
protected-mode no port 6380 replicaof 192.168.222.157 6379 daemonize no
dir /opt/redis/data/ 数据存储目录
#masterauth xd@2020 需要配置密码可加
#requirepass xd@2020 需要配置密码可加
7.将写好的配置文件放到redis对应的conf目录下
redis.conf配置介绍
bind 0.0.0.0 # 指定redis只接收来自于该IP地址的请求，如果不进行设置，那么将处理所有请求 port 6379 # redis监听的端口号 daemonize no # 是否在后台执行 logfile "6379.log" # 日志文件命名及路径 dbfilename "dump-6379.rdb" # 数据文件命名及路径 slaveof 192.168.12.222 6379 #新的redis版本支持 replicaof # 复制选项，slave复制对应的master appendonly yes # AOF数据持久化 appendfilename aof-6379.aof # AOF数据文件命名 appendfsync everysec # 写入策略，默认值everysec，每秒写一次(调用flush)。另外两个值，always | no,分别表示每次redis写命令之外就写文件，和由操作系统保证。always对硬盘压力大，everysec是一个平衡值,no对硬盘压力最小，但调度由系统控制，丢失数据风险最大. no-appendfsync-on-rewrite yes # 是否在后台写时同步单写，默认值no(表示需要同步).这里的后台写，表示后台正在重写文件(包括bgsave和bgrewriteaof.bgrewriteaof网上很多资料都没有涉及到。其实关掉bgsave之后，主要的即是aof重写文件了).no表示新的主进程的set操作会被阻塞掉，而yes表示新的主进程的set不会被阻塞，待整个后台写完成之后再将这部分set操作同步到aof文件中。但这可能会存在数据丢失的风险(机率很小)，如果对性能有要求，可以设置为yes，仅在后台写时会异步处理命令. auto-aof-rewrite-percentage 100 aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，aof文件过大而实际内存数据小的问题(频繁修改数据问题). auto-aof-rewrite-min-size 64mb aof文件重写最小的文件大小，即最开始aof文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了(根据上一次重写完成之后的大小).此变量仅初始化启动redis有效.如果是redis恢复时，则lastSize等于初始aof文件大小.
4.2 启动容器
启动master、slave容器
docker run --name myredis1 -d -v /root/redis1/conf/redis.conf:/usr/local/etc/redis/redis.conf -v /root/redis1/data:/data -p 6379:6379 redis redis-server /usr/local/etc/redis/redis.conf docker run --name myredis2 -d -v /root/redis2/conf/redis.conf:/usr/local/etc/redis/redis.conf -v /root/redis2/data:/data -p 6380:6380 redis redis-server /usr/local/etc/redis/redis.conf docker run --name myredis3 -d -v /root/redis3/conf/redis.conf:/usr/local/etc/redis/redis.conf -v /root/redis3/data:/data -p 6381:6381 redis redis-server /usr/local/etc/redis/redis.conf
4.3 测试主从复制
在master上创建key value
在slave上查看
至此，主从复制成功，另外一台slave就不看了，自信。
5. 部署哨兵
5.1 下载sentinel.conf文件
wget http://download.redis.io/redis-stable/sentinel.conf
5.2 配置sentinel.conf文件
（哨兵配置都一样，只修改port 26380 26381）
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 192.168.222.157 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
#sentinel auth-pass mymaster xd@2020 主从redis有密码时加
sentinel.conf配置介绍
daemonize yes # 后台执行
protected-mode no
# 关闭保护模式，即不使用密码就可以访问
dir "/data"
# 数据写入目录 logfile "26379.log" # 日志文件命名及路径 sentinel monitor mymaster 192.168.222.157 6379 2 # 该哨兵节点监控192.168.222.157 6379名称为mymaster的主节点，2代表需要2个哨兵节点同意才能判定主节点故障及开始故障转移 sentinel down-after-milliseconds mymaster 30000 # 指定30000毫秒后mymaster主节点被sentinel判定为不可用。默认30毫秒。 sentinel parallel-syncs mymaster 1 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步 # 这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。 # 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 sentinel failover-timeout mymaster 15000 #1.同一个sentinel对同一个master两次failover之间的间隔时间。 #2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。
5.2 启动redis哨兵容器
docker run --name mysentinel1 -d -v /root/redis4/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf -v /root/redis4/data:/data -p 26379:26379 redis redis-sentinel /usr/local/etc/redis/sentinel.conf
docker run --name mysentinel2 -d -v /root/redis5/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf -v /root/redis5/data:/data -p 26380:26380 redis redis-sentinel /usr/local/etc/redis/sentinel.conf
docker run --name mysentinel3 -d -v /root/redis6/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf -v /root/redis6/data:/data -p 26381:26381 redis redis-sentinel /usr/local/etc/redis/sentinel.conf
5.3 测试
现在停止当前redis master主节点，查看哨兵是否判定故障并迁移
docker stop myredis1
docker logs mysentinel1
1:X 16 Sep 2020 05:20:20.031 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:X 16 Sep 2020 05:20:20.031 # Redis version=6.0.7, bits=64, commit=00000000, modified=0, pid=1, just started
1:X 16 Sep 2020 05:20:20.031 # Configuration loaded
1:X 16 Sep 2020 05:20:20.032 * Running mode=sentinel, port=26379.
1:X 16 Sep 2020 05:20:20.032 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:X 16 Sep 2020 05:20:20.033 # Sentinel ID is 6d2cde4e8b3648a5299424e2fd1e628991d71ff3
1:X 16 Sep 2020 05:20:20.034 # +monitor master mymaster 192.168.222.157 6379 quorum 2
1:X 16 Sep 2020 05:20:20.034 * +slave slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:20:20.035 * +slave slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:22:42.815 * +sentinel sentinel cec9dd73202a580cf4703163037692584ed2e9ff 172.17.0.10 26380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:22:52.591 * +sentinel sentinel 1e8fd10c768640f7ee83d8de6e775285fad6ca94 172.17.0.11 26381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.308 # +sdown master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.409 # +new-epoch 1
1:X 16 Sep 2020 06:03:59.410 # +vote-for-leader 1e8fd10c768640f7ee83d8de6e775285fad6ca94 1
1:X 16 Sep 2020 06:03:59.840 # +config-update-from sentinel 1e8fd10c768640f7ee83d8de6e775285fad6ca94 172.17.0.11 26381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.840 # +switch-master mymaster 192.168.222.157 6379 172.17.0.1 6381
1:X 16 Sep 2020 06:03:59.840 * +slave slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 172.17.0.1 6381
1:X 16 Sep 2020 06:03:59.840 * +slave slave 192.168.222.157:6379 192.168.222.157 6379 @ mymaster 172.17.0.1 6381
我们发现，哨兵已将 192.168.222.157:6381 升级为master主节点，成功。
现在恢复192.168.222.157:6379的redis看看日志会打印什么？
[root@k8s-master docker]# docker start myredis1
myredis1
[root@localhost mnt]# docker logs mysentinel3
1:X 16 Sep 2020 05:22:50.523 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:X 16 Sep 2020 05:22:50.523 # Redis version=6.0.7, bits=64, commit=00000000, modified=0, pid=1, just started
1:X 16 Sep 2020 05:22:50.523 # Configuration loaded
1:X 16 Sep 2020 05:22:50.524 * Running mode=sentinel, port=26381.
1:X 16 Sep 2020 05:22:50.524 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:X 16 Sep 2020 05:22:50.528 # Sentinel ID is 1e8fd10c768640f7ee83d8de6e775285fad6ca94
1:X 16 Sep 2020 05:22:50.528 # +monitor master mymaster 192.168.222.157 6379 quorum 2
1:X 16 Sep 2020 05:22:50.530 * +slave slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:22:50.533 * +slave slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:22:50.930 * +sentinel sentinel cec9dd73202a580cf4703163037692584ed2e9ff 172.17.0.10 26380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 05:22:51.246 * +sentinel sentinel 6d2cde4e8b3648a5299424e2fd1e628991d71ff3 172.17.0.8 26379 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.334 # +sdown master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.405 # +odown master mymaster 192.168.222.157 6379 #quorum 2/2
1:X 16 Sep 2020 06:03:59.406 # +new-epoch 1
1:X 16 Sep 2020 06:03:59.406 # +try-failover master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.408 # +vote-for-leader 1e8fd10c768640f7ee83d8de6e775285fad6ca94 1
1:X 16 Sep 2020 06:03:59.410 # cec9dd73202a580cf4703163037692584ed2e9ff voted for 1e8fd10c768640f7ee83d8de6e775285fad6ca94 1
1:X 16 Sep 2020 06:03:59.410 # 6d2cde4e8b3648a5299424e2fd1e628991d71ff3 voted for 1e8fd10c768640f7ee83d8de6e775285fad6ca94 1
1:X 16 Sep 2020 06:03:59.460 # +elected-leader master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.460 # +failover-state-select-slave master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.532 # +selected-slave slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.532 * +failover-state-send-slaveof-noone slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.595 * +failover-state-wait-promotion slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.789 # +promoted-slave slave 172.17.0.1:6381 172.17.0.1 6381 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.789 # +failover-state-reconf-slaves master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:03:59.839 * +slave-reconf-sent slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:04:00.481 # -odown master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:04:00.856 * +slave-reconf-inprog slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:04:00.856 * +slave-reconf-done slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:04:00.915 # +failover-end master mymaster 192.168.222.157 6379
1:X 16 Sep 2020 06:04:00.915 # +switch-master mymaster 192.168.222.157 6379 172.17.0.1 6381
1:X 16 Sep 2020 06:04:00.915 * +slave slave 172.17.0.1:6380 172.17.0.1 6380 @ mymaster 172.17.0.1 6381
1:X 16 Sep 2020 06:04:00.915 * +slave slave 192.168.222.157:6379 192.168.222.157 6379 @ mymaster 172.17.0.1 6381
1:X 16 Sep 2020 06:04:30.979 # +sdown slave 192.168.222.157:6379 192.168.222.157 6379 @ mymaster 172.17.0.1 6381
1:X 16 Sep 2020 06:11:08.621 # -sdown slave 192.168.222.157:6379 192.168.222.157 6379 @ mymaster 172.17.0.1 6381
1:X 16 Sep 2020 06:11:22.954 * +slave slave 172.17.0.1:6379 172.17.0.1 6379 @ mymaster 172.17.0.1 6381
192.168.222.157:6379已经成为192.168.222.157:6381的从节点。那么本次部署结束。
