前言
redis的高可靠性体现在:
1.数据尽量少丢失
2.服务尽量少中断
前者体现在AOF日志和RDB快照的数据可持久化手段上，而后者是增加副本的冗余量，即将一份数据保存在多个实例上(即使一个实例挂掉，其他实例也能对外服务，也就是主从复制)
思考
- 主从复制为什么采用读写分离的方式？
- 主从复制第一次采用全量复制当从库数量太多，如何分担主库压力
- 什么是全量复制和增量复制
- 为什么要用RDB不用AOF
主从复制
实验（一主一从）
准备:相同的redis.conf文件
文件夹创建:
文件夹准备
编写master.sh和slave.sh（注意slave.sh修改端口 -p或者不加）
#! /bin/bash
docker run -d -p 6379:6379 --name master -v /home/docker/redis/master/redis.conf:/etc/redis/redis.conf -v /home/docker/redis/master/data:/data redis:5.0.5 redis-server /etc/redis/redis.conf
启动master容器并验证
./master.sh
docker exec -it master redis-cli
set name zly
退出记录容器IP
docker inspect master //看ipaddress
进入slave文件夹修改redis.conf
replicaof 172.17.0.2 6379 //master容器虚拟ip和开放端口
masterauth 123456 //master容器有设置密码就添加这个
这里要注意5.0.5版本之后slaveof修改为replicaof，至于为啥改这个名字，好像跟redis作者的政治倾向有关（他自己讲的）
运行slave容器并进入查看slave的实例有没有name键
get name // zly
查看master和slave日志
docker logs master
master
提示success
主从复制都干了啥
根据master日志我们看看
1.Ready to accept connections，Replica 172.17.0.3:6379 asks for synchronization
这里从库给主库发送psync命令，表示要建立连接进行数据同步，主库根据这个命令的参数来启动复制，psync命令包含了主库的runID(redis启动时会自动生成)和复制进度offset两个参数(-1表示第一次复制)
2.Full resync requested by replica 172.17.0.3:6379
172.17
主库发送FULLRESYNC命令（携带上面两个参数）进行确认
FULLRESYNC响应表示第一次采用全量复制(复制全部数据)
3.RDB: 6 MB of memory used by copy-on-write
主库执行bgsave命令，生成并发送RDB文件给从库，进行数据的同步，从库会在此前先清空当前数据库
试试向主库写入数据
写入数据后的日志
主库会在内存中用专门的replication buffer记录RDB文件生成后的收到的写操作，并把其中的修改操作发送给从库
主从网络断了怎么办（假设从实例挂掉了）
redis的解决方案就是使用增量复制
实验
docker stop slave
docker exec -it master redis-cli
set sex 1
docker start slave
查看日志
1:M 01 Mar 2021 15:38:13.539 * Replica 172.17.0.3:6379 asks for synchronization
1:M 01 Mar 2021 15:38:13.539 * Partial resynchronization request from 172.17.0.3:6379 accepted. Sending 29 bytes of backlog starting from offset 5459.
我们看到从库宕机重连后并没有进行再一次的全量复制，而是将增加后的数据发给从库。
当主从断连后，主库会把断链期间收到的写命令写入replication buffer(上面有提到)，同时也会写入repl_backlog_buffer这个缓冲区。
repl_backlog_buffer是一个环形缓冲区(类似mysql的redolog)，主库记录自己写到的位置，从库记录自己读到的位置。
从repl_backlog_buffer偏移位置出发:
1.刚开始主从库都位于repl_backlog_buffer的起始位置
2.主库不断接受写操作，主库的repl_backlog_buffer位置发生偏移master_repl_offset
3.从库复制写命令也不断偏移slave_repl_offset
4.从库断开连接后重连，除了发送psync命令还会发送slave_repl_offset
5.主库计算master_repl_offset和slave_repl_offset偏移差，并将期间的命令发送给从库(set sex 1)
repl_backlog_buffer被写满了怎么办
因为是环形的，那么写满后再写入，那么最先写入repl_backlog_buffer的就会被覆盖，出现主从数据不一致的情况
如何设置配置中的repl_backlog_size就显得很重要
思考
- 主从复制采用读写分离的原因
1.主从都可读
2.写操作都在主库执行，然后将写操作同步给从库
初始化(set name old)，从读操作方面出发，无论是主库(v)和从库(v1,v2)因为保存的都是相同的数据都可以执行。当客户端对name分别在不同的实例上进行三次修改，假设(什么方案都没做)主从都能接受写操作，那么这三个不同的实例上的副本就不一致（在读取的时候可能读取到旧值）。那么要保证我们不会读到旧值或者说保持name这个缓存在三个实例上都是新鲜的，都是最后一次修改的，我们就需要在每次写操作时进行加锁、实例协商是否完成修改等操作，这巨大的开销是可想而知的。
-主从复制第一次采用全量复制当从库数量太多，如何分担主库压力
"主-从-从"的方式是解决这个问题的一个方案，即将中间的从库作为主库，分担真正主库的生成传输RDB文件压力
网友评论