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等。