主从复制
单机部署存在的问题：机器故障(高可用问题)，容量瓶颈和QPS瓶颈(分布式问题)。
主从复制的作用：
1.备份 主添加一条数据 从 也添加一条，这样主数据库宕机从数据库可以提供支援。
2.一主多从 可以实现读写分离，将读操作分流操作 提高效率和负载均衡。
实现方式：
命令实现：
1.从节点执行命令： slaveof 主节点IP 端口。
slaveof no one 不希望成为任何主节点的从节点，这个时候会把主从连接清除，当然也可以重新和别的主节点建立连接 但是建立后会先把从节点数据清除。
配置实现：
1.slaveof ip prot ；
masterauth 主节点密码；
2.slave-read-only yes：只允许读，这样可以保证主 从两个节点的一致性 达到高可用的目的。
比较：
redis-cil -p 端口 登陆后 输入命令 info replication --查看redis主从复制信息
当前为主节点 连接的从节点为0个
当前为从节点，下面是主节点IP 端口 以及连接状态
全量配置
每个redis都会有一个runId，当服务器重新启动后 runId更改。在主从复制中，当主服务器的runId进行了修改，从服务器会将主服务器的数据全部同步过来，就是全量复制。
全量复制过程：
1.slave请求主服务器，master发现是第一次连接。
2.master把自己的runId和offset发送给slave，其中runId master重启后会改变，offset代表当前数据存储的大小，全量复制和部分复制都会用它做对比。
3.slave保存master的信息。
4.master 通过bgsave进行快照(持久化)，同时在RDB生成和传输的过程的新增命令进行缓存。
5.发送RDB文件。
6.发送新增的命令。
7.slave首先清除自己的数据。
8.将RDB以及buffer数据加载入slave。
开销：
1.basave时间
2.Rdb文件网络传输
3.从节点数据清除
4.从节点加载RDB的时间
５.可能的AOF重写，保证AOF的是最新的
可能出现的问题：如果主从之间网络出现了问题 那么这段时间内主的数据是不会更新到从的。
部分复制
部分复制过程：
1.当网络发生抖动 连接断开
2.master会将数据先存入缓冲区
3.slave将自身的offset和runId传入master
4.如果slave中的offset在master之内那么continue
5.master将slave中的offset为起点 到自己本身offset的最后（类似一个队列） 发送给slave实现部分复制
自动故障转移：
slave宕机：不会影响master 如果做了读写分离，那么将当前slave改到别的slave就可以，当然前提是这个slave可以支撑多个应用，那只要重启改动的应用就可以。
mester宕机：选择一个从节点成为主节点，另一个从节点成为新的主节点的从节点，实现读写分离。
启用从节点为主节点。命令：slaveof no one
旧节点变成新主节点的从节点。 命令：slaveof new master
常见问题：
1.读写分离，读流量分摊到从节点
-
复制数据延迟:当发生特殊情况导致写入的数据没有及时从主节点同步到从节点，这个时候读取从节点的时候读不到数据；
-
读取到过期数据，因为主从节点有约定，从节点不可以删除数据，那么如果这个时候主节点没有删除数据并同步到从接口，那么从节点就可能读取到过期数据，redis三种删除策略自行百度；
-
从主点故障；
2.主从复制不一致
- 例如maxmemory不一致：丢失数据；
3.规避全量复制
-
第一次不能避免
- 小主节点 生成db文件的小点
- 低峰时候处理比如夜间
-
主节点从新运行也不能避免，好的方法是用故障转移
-
复制积压缓冲区不足
- 网络中断不能复制
- 增大复制缓冲区配置 rel_backlog_size ，网络增强
4.规避复制风暴