基于Redis版本： redis-6.0.5
主从复制
▶ 避免redis单点故障
▶ 构建读写分离架构，满足读多写少的应用场景
主从架构
一：Redis安装
官网地址：https://redis.io/
下载、解压、复制：
wget http://download.redis.io/releases/redis-6.0.5.tar.gz # 下载
tar -zxvf redis-6.0.5.tar.gz #解压
mv redis-6.0.5/ redis6379 #重命名
cp -r redis6379/ redis6380 #复制
cp -r redis6379/ redis6381 #复制
编译：
cd redis6379 #进入目录
make #编译
make命令可能出现的问题、以及解决方案
错误一：cc：命令未找到
解决方案：yum install gcc
错误二：致命错误：jemalloc/jemalloc.h：没有那个文件或目录
解决方案：使用 make MALLOC=libc 命令代替 make
错误三：突然一大推错误和警告，报错信息如下
解决方案：升级gcc版本到9.1，再执行编译
# gcc -v # 查看gcc版本
# yum -y install centos-release-scl # 升级到9.1版本
# yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
# scl enable devtoolset-9 bash
复制常用操作命令到上一级：
cp src/redis-cli ./ #复制命令 （这两步可以省略，只为了操作起来方便）
cp src/redis-server ./ #复制命令
redis6380、redis6381执行同样的编译操作
二：修改redis.conf
redis6379/redis.conf
port 6379 # 端口
pidfile /var/run/redis_6379.pid # pid文件位置
daemonize yes # 开启支持后台启动
requirepass 123456 # 开启密码验证
# bind 127.0.0.1 # 注释这一句，让redis支持ip访问
redis6380/redis.conf
port 6380 # 端口
pidfile /var/run/redis_6380.pid # pid文件位置
daemonize yes # 开启支持后台启动
requirepass 123456 # 开启密码验证
# bind 127.0.0.1 # 注释这一句，让redis支持ip访问
redis6381/redis.conf
port 6381 # 端口
pidfile /var/run/redis_6381.pid # pid文件位置
daemonize yes # 开启支持后台启动
requirepass 123456 # 开启密码验证
# bind 127.0.0.1 # 注释这一句，让redis支持ip访问
三：配置主从
▶ 在从redis服务的redis.conf中设置 replicaof<masterip> <masterport>
配置 6380 和 6381 的redis.conf
启动redis
/usr/local/redis6379/redis-server /usr/local/redis6379/redis.conf
/usr/local/redis6380/redis-server /usr/local/redis6380/redis.conf
/usr/local/redis6381/redis-server /usr/local/redis6381/redis.conf
连接客户端，查看主从信息：info replication
主(6379)：
从(6380)：
四：读写分离
在主库写入数据：
在从库读取数据：
tip：默认情况下，从redis数据库是只允许读操作的，不能进行写操作。
开启slave非只读：slave-read-only no（不建议做，会导致主从数据不一致）
主从复制过程
1：当从库和主库建立MS（主从）关系后，会向主数据库发送SYNC（同步）命令；
2：主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；
3：当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；
4：从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；
5：之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；
五：主从架构中出现宕机怎么办
如果在主从复制架构中出现宕机的情况，需要分情况看：
● 从Redis宕机
策略：重新启动从数据库，会自动加入到主从架构中，自动完成同步数据；
● 主Redis宕机
第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；
第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；
主数据库宕机后的手动完成恢复的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，Redis提供的哨兵（sentinel）的功能。
六：redis哨兵
1：哨兵是什么？
哨兵的作用就是对Redis的系统的运行情况的监控，它是一个独立进程
2：哨兵的作用？
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
· 提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
· 自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
单哨兵监控
配置单哨兵监控
1：修改哨兵文件 sentinel.conf
vim redis6379/sentinel.conf
2：修改内容
mymaster：监控主数据的名称，支持自定义
127.0.0.1：监控的主数据库的IP
6379：监控的主数据库的端口
1：最低通过票数
3：启动哨兵进程：
cd redis6379/ #进去redis安装目录
cp src/redis-sentinel ./ #复制哨兵服务启动命令
./redis-sentinel sentinel.conf #启动哨兵服务
由上图可以看到：
1：哨兵已经启动，它的id为0e786aa868334de731814accecb107a35c0a5320
2：为master数据库添加了一个监控
3：发现了2个slave（由此可以看出，哨兵无需配置slave，只需要指定master，哨兵会自动发现slave）
测试从库宕机
查看哨兵控制台输出
+sdown：服务宕机，说明哨兵监控到slave宕机了，那么，如果我们将宕机的slave服务重启后，会自动加入到主从复制吗？
重新启动后，查看哨兵控制台输出
-sdown：服务恢复，可以看出slave重新加入了主从架构中
测试主库宕机
查看哨兵控制台输出
连接6381查看状态
可以看出，目前，6381位master，拥有一个slave为6380.
接下来，我们恢复6379查看哨兵控制台输出：
测试发现：主库宕机后，会将一个从库选为主，当宕机的主库重新连接时，也只能作为新主库的小弟了。
配置多个哨兵
配置了一个哨兵,如果该哨兵宕机了,那么整个主从架构就回复到了原始的情况,所以我们可以配置多个哨兵,每个哨兵监控Redis信息,并且哨兵之间也会互相监控。哨兵也具有类似zookeeper的选举机制，所以测试配置三个哨兵。
修改sentinel.conf
vim redis6379/sentinel.conf
设置最低通过票数为 2，并且设置哨兵服务支持后台启动
复制两份哨兵文件
cp sentinel.conf sentinel_1.conf
cp sentinel.conf sentinel_2.conf
修改sentinel_1.conf、sentinel_1.conf的port
启动哨兵
./redis-sentinel sentinel.conf
./redis-sentinel sentinel_1.conf
./redis-sentinel sentinel_2.conf
效果测试和一个哨兵差不多。有兴趣的自己去玩一下。
哨兵学习博客：https://blog.csdn.net/a67474506/article/details/50435498
上一篇：redis数据持久化
下一篇：redis4.x 主从集群的搭建