05-Redis系列之-主从复制配置和优化，fork和aof两大阻塞
主从复制
原理
一台主服务器配多台从服务器，主服务器宕机后，从服务器挑选一台顶上去。
从服务器同步主服务器的数据，这个同步是单向的，并且从服务器不能设置值，否则会造成数据的混乱
功能
0.故障处理：slave故障，master故障
1.解决机器故障；容量瓶颈；QPS瓶颈
2.一主一从，一主多从
3.做读写分离
4.做数据副本
5.扩展数据性能
6.一个maskter可以有多个slave
7.一个slave只能有一个master
8.数据流向是单向的，从master到slave
主从配置操作
# 6379是主，6380是从，在6380上执行（去从库配置，链接主库）
1.在从库执行（链接主库的主机和端口）
slaveof 127.0.0.1 6379
# 断开关系，取消复制，不会把之前的数据清除
slaveof no one
2.配置文件（配在从库的配置文件中）
slaveof 127.0.0.1 6379
# 从库节点只读，因为可读可写，数据会乱
slave-read-only yes
# docker配置一主两从
# docker学习：https://www.cnblogs.com/hkwJsxl/p/17164139.html
'''
cd /home/
mkdir -p redis1/conf redis1/data redis2/conf redis2/data redis3/conf redis3/data
mkdir /home/conf
vim /home/conf/redis.conf
# redis.conf配置(10.0.0.10是虚拟机的ip)
daemonize no
pidfile redis.pid
bind 0.0.0.0
protected-mode no
port 6379
timeout 0
logfile redis.log
dbfilename dump.rdb
dir ./
slaveof 10.0.0.10 6379
# 主机是no，从机是yes
slave-read-only yes
cp /home/conf/redis.conf /home/redis1/conf/redis.conf
cp /home/conf/redis.conf /home/redis2/conf/redis.conf
cp /home/conf/redis.conf /home/redis3/conf/redis.conf
docker run -p 6379:6379 --name redis_6379 -v /home/redis1/conf/:/etc/redis/ -v /home/redis1/data:/data -d redis:redis7 redis-server /etc/redis/redis.conf
docker run -p 6378:6379 --name redis_6378 -v /home/redis2/conf/:/etc/redis/ -v /home/redis2/data:/data -d redis:redis7 redis-server /etc/redis/redis.conf
docker run -p 6377:6379 --name redis_6377 -v /home/redis3/conf/:/etc/redis/ -v /home/redis3/data:/data -d redis:redis7 redis-server /etc/redis/redis.conf
info replication
'''
复制常见问题
-
读写分离
-
读流量分摊到从节点
-
可能遇到问题：复制数据延迟，读到过期数据，从库节点故障
-
-
主从配置不一致
-
maxmemory不一致：丢失数据 -
数据结构优化参数：主节点做了优化，从节点没有设置优化，会出现一些问题
-
-
规避全量复制
-
第一次全量复制，不可避免：小主节点，低峰(夜间)
-
节点运行id不匹配：主节点重启(运行id变化)
-
复制挤压缓冲区不足：增大复制缓冲区大小，rel_backlog_size
-
-
规避复制风暴
- 单主节点复制风暴，主节点重启，所有从节点复制
子进程开销和优化
cpu
开销：rdb和aof文件生成，属于cpu密集型
优化：不做cpu绑定，不和cpu密集型的服务一起部署
内存
开销：fork内存开销，copy-on-write，
优化：单机部署尽量少重写
硬盘
开销：aof和rdb写入，可以结合分析工具使用
优化：
- 不要和高硬盘负载的服务部署在一起：存储服务，消息队列
- 在
aof重写期间，不要对aof进行追加：no-appendfsync-on-rewrite=yes - 根据写入量决定磁盘类型：例如
ssd - 单机多实例持久化考虑分盘
两大阻塞
fork阻塞：CPU的阻塞
在Redis中，众多因素导致Redis单机内存不能过大。
- 当面对请求暴增时，需要从库扩容，如果单机内存过大会导致扩容时间过长；
- 当主机宕机后，切换主机需要重新挂载从库，
Redis内存过大会导致挂载速度过慢； - 持久化过程中的fork操作
fork操作
fork是同步操作，与内存量息息相关：内存越大，耗时越长，跟机型也有关系
info：latest_fok_usec：查看持久化执行时间
改善fork：
-
有限使用无机或高效支持fork操作的虚拟化技术
-
控制
redis实例最大可用内存：maxmemory -
合理配置
linux内存分配策略 -
降低fork频率，例如放宽
aof重写自动触发时机，不必要的全量复制
aof追加阻塞
在AOF中，如果AOF缓冲区的文件同步策略为everysec，则在主线程中，命令写入aof_buf后调用操作系统write操作，write完成后主线程返回；fsysnc同步文件操作由专门的文件同步线程每秒调用一次。
这种做法的问题在于，如果硬盘负载过高，那么fsysnc操作可能会超过1s；如果Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗会更快。如果此时Redis异常退出，会导致数据丢失可能远超过1s。
为此，Redis的处理策略是这样的：主线程每次进行AOF会对比上次fsync成功的时间；如果距上次不到2s，主线程直接返回；如果超过2s，则主线程阻塞直到fsync同步完成。因此，如果系统硬盘负载过大导致fsync速度太慢，会导致Redis主线程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的数据，而不是1s。
问题
aof everysec配置最多可能丢失2秒数据，不是1秒。
如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率。
AOF追加阻塞问题定位的方法：
-
监控
redis-cli info persistence中的aof_delayed_fsync：当AOF追加阻塞发生时（即主线程等待fsync而阻塞），该指标会累加。 -
看日志：
AOF阻塞时的Redis日志：
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
- 如果
AOF追加阻塞频繁发生，说明系统的硬盘负载太大；可以考虑更换IO速度更快的硬盘，或者通过IO监控分析工具对系统的IO负载进行分析，如iostat（系统级io）、iotop（io版的top）、pidstat等。
