Redis主从复制
单机有什么问题？
单机即在一台机器上部署一个redis节点，主要会存在以下问题：
1. 机器故障
如果发生机器故障，例如磁盘损坏，主板损坏等，未能在短时间内修复好，客户端将无法连接redis。
当然如果仅仅是redis节点挂掉了，可以进行问题排查然后重启，姑且不考虑这段时间对外服务的可用性，那还是可以接受的。
而发生机器故障，基本是无济于事。除非把redis迁移到另一台机器上，并且还要考虑数据同步的问题。
2. 容量瓶颈
假如一台机器是16G内存，redis使用了12G内存，而其他应用还需要使用内存，假设我们总共需要60G内存要如何去做呢，是否有必要购买64G内存的机器？
3. QPS瓶颈
redis官方数据显示可以达到10w的QPS，如果业务需要100w的QPS怎么去做呢？
关于容量瓶颈和QPS瓶颈是redis分布式需要解决的问题，而机器故障就是高可用的问题了。
主从复制的作用
一主一从
如图所示左边是Master节点，右边是slave节点，即主节点和从节点。从节点也是可以对外提供服务的，主节点是有数据的，从节点可以通过复制操作将主节点的数据同步过来，并且随着主节点数据不断写入，从节点数据也会做同步的更新。
整体起到的就是数据备份的效果。
一主多从
除了一主一从模型之外，redis还提供了一主多从的模型，也就是一个master可以有多个slave，也就相当于有了多份的数据副本。
这样可以做一个更加高可用的选择，例如一个master和一个slave挂掉了，还能有其他的slave数据备份。
读写分离
除了作为数据备份，主从模型还能做另外一个功能，就是读写分离。
让master节点负责提供写服务，而将数据读取的压力进行分流和负载，分摊给所有的从节点。
主从复制的作用
- 数据副本(备份)
- 扩展读性能(读写分离)
简单总结
- 一个master可以有多个slave
- 一个slave只能有一个master
- 数据流向是单向的，master到slave
主从复制的配置
1. slaveof命令
如图，想让6380节点成为6379的从节点，只需要执行 slaveof 命令即可，此复制命令是异步进行的，redis会自动进行后续数据复制的操作。
注：一般生产环境不允许主从节点都在一台机器上，因为没有任何的价值。
取消复制
如果6380节点不希望成为6379的从节点，可以执行 slave of on one 命令，取消后6380节点的数据不会被清除，只是说后续6379节点新写入的数据不会再同步到该节点了。
注意：如果取消复制后想slave一个新的主节点，新的主节点在同步给slave节点数据时，会先将从节点的数据全部清除
2. 修改配置
# 配置主节点的IP和端口号
slaveof ip port
# 从节点只做读的操作，保证主从数据的一致性
slave-read-only yes
对比
runid和复制偏移量
redis每次启动的时候都会有一个随机的ID，作为一个标识，这个ID就是runid，当然重启之后值就改变了。
查看runid：redis-cli -p 6379 info | grep run
假如端口为6380的redis去复制6379，知道runid后，在6380上做一个标识，如果runid改变了，说明主可能重启了或者发生了其它变化，这时候就可以做一个全量复制把数据同步过来。或者第一次启动时根本不知道6379的runid，也会进行全量复制
偏移量：数据写入量的字节
比如主执行set hello world，就会有一个偏移量，然后从同步数据，也会记录一个偏移量
当两个偏移量达到一致时候，实际上数据就是完全同步的状态。
启动主从redis，并在写入命令执行前后查看主偏移量：
redis-cli -p 6379 info replication | grep master_repl
从节点会向主节点做一个上报，把从节点的状态同步给主节点，这样主节点就知道了从节点的偏移量
生产环境我们一般不关心这个值，有时候做监控的时候会比对一下这两个值的差，如果差的太多，说明主从是有问题的。
全量复制
全量复制主节点会将RDB文件也就是当前状态去同步给slave，在此期间主新写入的命令会单独记录起来，然后当RDB文件加载完毕之后，会通过偏移量对比将这个期间产生的写入值同步给slave，这样就能达到数据完全同步的效果
全量复制过程
- 在其内部有一条命令
psync，是做同步的命令，它可以完成全量复制和部分复制的功能，当启动slave节点时，它会发送psync命令给主节点，需要传递两个参数，runid和offset(偏移量)，也就是从向主传递主节点的runid以及自己的偏移量，对于第一次复制而言，就直接传递？和 -1，当然这个参数是由slave内部传的。 - master接收到命令后知道从希望做全量复制，主就会将自己的runid和offset传递给从
- slave节点保存master的基本信息
- master执行
bgsave生成RDB文件，并且在此期间新产生的写入命令会被记录到repl_back_buffer(复制缓冲区) - 主向从传输RDB文件
- 主向从发送复制缓冲区内容
- 清空从节点旧的数据
- 从节点加载RDB文件到内存中，同时加载缓冲区数据
全量复制的开销
实际上全量复制的开销是非常大的，主要体现在如下方面
- bgsave时间(对cpu、 内存、硬盘都会有一定的开销)
- RDB文件网络传输时间(网络带宽)
- 从节点清空数据时间(根据从节点的数据规模)
- 从节点加载RDB的时间
- 可能的AOF重写时间(在最后从加载完RDB之后如果开启了AOF，会做AOF重写)
全量复制除了上述开销之外，还会有个问题：
假如master和slave网络发生了抖动，那一段时间内这些数据就会丢失，对于slave来说这段时间master更新的数据是不知道的。最简单的方式就是再做一次全量复制，从而获取到最新的数据，在redis2.8之前是这么做的。
部分复制
部分复制，redis2.8之后提供。如果发生类似抖动时候，可以有一种机制将这种损失降低到最低，如何实现的？
- 如果发生了抖动，相当于连接断开了
- 主会将写命令记录到缓冲区，repl_back_buffer
- 当slave再次去连接master时候，就是说网络抖动结束之后，会触发增量复制
- 从会执行pysnc命令，将当前自己的offset和主的runid传递给master
- 如果发现传输的offset偏移量是在buffer内的，不在期间内就证明你已经错过了很多数据，buffer也是有限的，默认是1M，会将offset开始到队列结束的数据同步给从。这样master和slave就达到了一致。
通过部分复制(增量复制)有效的降低了全量复制的开销。
复制的相关配置
无磁盘化复制
# 开启无磁盘化复制
repl-diskless-sync yes
# 当收到第一个复制请求时，等待 5s 后再开始复制，因为要等更多 slave 一起连接过来
repl-diskless-sync-delay 5
复制的限制
如果在复制期间，rdb复制时间超过60秒，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么将会停止复制(失败)
配置项：client-output-buffer-limit slave 256MB 64MB 60
`
