1.单机有什么问题
- 机器故障
- 容量瓶颈
- QPS瓶颈
2. 主从复制的作用
- 数据副本
扩展读性能
一个master可以有多个slave
- 一个salve只能有一个master
3. 两种实现方式
方式一：slaveof命令
slaveof masterIp masterPort
slaveof no one(不会清除原来同步的数据，而是新的数据不会再同步给他)
方式二：配置
修改某一行的配置：slaveof ip port
从节点只做读操作：slave-read-only yes
对比
命令的优点：不需要重启
命令的缺点：不便于管理
配置的优点：统一配置
配置的缺点：需要重启
一个场景，加入6380是6379的一个从节点，然后将6380执行salveof no one，然后插入一些新的数据；再重新变成6379的从节点，那么里面的新数据会被清除掉。
查看run_id
redis-cli -p 6379 info server | grep run
4. 全量复制
全量复制开销
bgsave时间
rdb网络传输时间
从节点清空数据的时间
从节点加载RDB的时间
可能的AOF重写时间
存在的问题
时间开销比较大
如果master和slave之间网络扰动甚至断开，那么master此间更新的数据对于slave是不知道的，最简单的方法就是再进行一次全量复制，但是显然，消耗太大了。
5. 部分复制
6. 开发与运维的问题
- 读写分离
master只做写操作，slave来做读操作，来分摊流量。但是会有一些问题：
复制数据延迟
读到过期数据
从节点故障
- 主从配置不一致
例如maxmemory不一致：丢失数据
数据结构优化参数：内存不一致
- 规避全量复制
第一次全量复制：不可避免—小主节点(maxmemroy不要太大)或者在低峰时进行操作
节点run_id不匹配（主节点重启，那么master的run_id会发生变化，slave发现其run_id变化，会进行全量复制）；我们可以用故障转移，例如哨兵或集群来避免全量复制
复制积压缓冲区不足(网络中断，部分复制无法满足)，可以增大复制缓冲区配置size，网络增强
- 规避复制风暴
概念：主节点宕机造成大量的全量复制
单主节点复制风暴：主节点重启，多从节点复制；解决：更换复制拓扑
单机器复制风暴：机器宕机后（该机器全是Mater），大量全量复制。解决：master分散多机器。
说到底，还是需要有一种高可用的实现方式，在master出现故障之后，如何自动实现从slave晋升为master继续使用.