主从复制
原理
一台主服务器配多台从服务器,主服务器宕机后,从服务器挑选一台顶上去。
从服务器同步主服务器的数据,这个同步是单向的,并且从服务器不能设置值,否则会造成数据的混乱
功能
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
等。