主从复制原理与优化
1 什么是主从复制
在软件的架构中，主从模式（Master-Slave）是使用较多的一种架构。主（Master）和从（Slave）分别部署在不同的服务器上，当主节点服务器写入数据时，同时也会将数据同步至从节点服务器，通常情况下，主节点负责写入数据，而从节点负责读取数据。
机器故障；容量瓶颈；QPS瓶颈
一主一从，一主多从
做读写分离
做数据副本
扩展数据性能
一个maskter可以有多个slave
一个slave只能有一个master
数据流向是单向的，从master到slave，也就是说slave只能读
1.1 原理
1. 副本库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照，持久化数据
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库
7. 所有复制相关信息,从info信息中都可以查到，即使重启任何节点,他的主从关系依然都在
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的1.2 主库是否要开启持久化
如果不开有可能，主库重启操作，造成所有主从数据丢失！1.3 辅助配置
主从数据一致性配置
min-slaves-to-write 1
min-slaves-max-lag 3
#在从服务器的数量少于1个，或者三个从服务器的延迟（lag）值都大于或等于3秒时，主服务器将拒绝执行写命令
2 主从模式实现
Redis 提供了两种实现主从模式的方法。为了方便演示，我们只从一台机器上搭建主从模式，启动两个redis进程，一个监听6379，一个监听6380。
1) 使用命令实现
使用命令在服务端搭建主从模式，其语法格式如下：
redis-server --port <slave-port> --slaveof <master-ip> <master-port>方式一：启动从服务端时，指定主服务器
# 开启开启一个port为6380的从机，它依赖的主机port=6379
C:\Users\Administrator> redis-server --port 6380 --slaveof 127.0.0.1 6379方式二：客户端连接到从服务器，通过命令指定主服务器
# 先启动两个redis服务端，以6380为从，6379为主
# 客户端连接6380，开启主从复制
slaveof 127.0.0.1 6379 #异步
# 客户端连接6380，取消主从复制，6380切换回独立主机，但不会把之前的数据清除
slaveof no one2) 修改配置文件实现
配在从库的配置文件中
新建 redis_6380.conf 文件,并添加以下配置信息：
slaveof 127.0.0.1 6379 #指定主机的ip与port
slave-read-only yes #从库只读，不能让数据写乱
3 主从模式不足
主从模式并不完美，它也存在许多不足之处，下面做了简单地总结：
- 1) Redis 主从模式不具备自动容错和恢复功能，如果主节点宕机，Redis 集群将无法工作，此时需要人为干预，将从节点提升为主节点。
- 2) 如果主机宕机前有一部分数据未能及时同步到从机，即使切换主机后也会造成数据不一致的问题，从而降低了系统的可用性。
- 3) 因为只有一个主节点，所以其写入能力和存储能力都受到一定程度地限制。
- 4) 在进行数据全量同步时，若同步的数据量较大可能会造卡顿的现象。
虽然主从模式存在上述不足，但它仍是实现分布式集群的基础。后续将介绍Redis-Sentinel哨兵模式，它同样依赖于主从模式实现。
4 故障处理
slave故障
master故障
5 主从复制常见问题
1 读写分离
读流量分摊到从节点
可能遇到问题：复制数据延迟，读到过期数据，从节点故障
2 主从配置不一致
maxmemory不一致：丢失数据
数据结构优化参数：主节点做了优化，从节点没有设置优化，会出现一些问题
3 规避全量复制
第一次全量复制，不可避免：小主节点，低峰(夜间)
节点运行id不匹配：主节点重启(运行id变化)
复制挤压缓冲区不足：增大复制缓冲区大小，rel_backlog_size
4 规避复制风暴
单主节点复制风暴，主节点重启，所有从节点复制
