主从的架构：
一主多从，级联
主从复制
1.s初次链接到m，发送sync命令，会触发一次全量复制。
2.m新开后台线程，生成一份RDB快照，同时将客户端发来的写命令，缓存在内存中
3.RDB生成后，发送给s，s收到后先写入磁盘，再加载到内存中。
4.m还会将缓存中的写命令，异步发送给s。
同步是由s发起
初次同步和部分重同步期间，m是非阻塞的，也就是还能提供对外服务。
部分重同步依赖一个偏移量，同时存在于m和s，再次连接上，s会向m发送偏移量，m进行比较，然后把偏移量后的命令发送给s。（特例：断开连接时间过长、偏移量已被覆盖<偏移量存在于m的复制积压缓冲区，默认1MB>，此时启动RDB全量同步）
常见问题
故障转移的策略：优先级最高（数越小）-偏移量最大-runid最小的从服务
全量复制问题：首次同步不可避免，后面尽量避免
1）m发生故障时，可能会导致runid变化，s会认为是一个全新的m。所以用哨兵、集群的方式来避免
2）复制积压缓冲区不足，也会导致。调大即可
3）复制风暴：主节点重启，大量s开启复制。通过树状级联的复制结构减轻压力。
----------
生成RDB日志的流程：https://blog.csdn.net/sj15814963053/article/details/124422938?spm=1001.2014.3001.5502
fork子进程进行，采用Copy-On-Write技术，同时正常处理读写
在复制时正好有个修改操作（修改已有数据A），A被复制一份A ^，子进程复制的是A，而修改操作的是A^
（开启RDB持久化后，当达到持久化的阈值，redis会fork一个新的进程来做持久化，采用了操作系统的copy-on-wirte写时复制策略，子进程与父进程共享Page。如果父进程的Page（每页4K）有修改，父进程自己创建那个Page的副本，不会影响到子进程；）
所以下面这个案例内存分析部分，有80% * 2G=1.6G
AOF重写：单写一个文件，合并命令，目的是减小AOF文件大小
AOF日志由主线程写入。是先执行数据写入命令，然后再写日志；但是AOF重写是后台子进程来写。
- 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值（新的增量达到了上次重写后文件大小的百分比）。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage
https://blog.csdn.net/sj15814963053?type=blog
