redis复制原理和应用
说到分布式高可用，必然少不了复制，一来是为了做个冗余备份防止数据丢失，二来还可以达到分流来提高性能的目的。基本架构：
下面用M表示Master（主服务器），S表示Slave（从服务器），话不多说，先敲代码
2.配置
slaveof 192.168.1.1 6379
在S端配置slaveof就可以实现复制了，意思是我从192.168.1.1 6379这台M复制数据。注意第一次复制的时候S上面的数据会被覆盖。下面就在我的虚拟机上面实操一下，配置3台redis，6379是M，6380、6381是S
配置M
$ cp redis.conf redis_6379.conf $ vi redis_6379.conf bind 192.168.56.10 #修改ip为本机
配置S
$ cp redis_6379.conf redis_6380.conf $ vi redis_6380.conf #修改端口号和pid文件名 port 6380 pidfile /var/run/redis_6380.pid slaveof 192.168.56.10 6379 #设定复制 #同样拷贝一份配置按照上面的步骤修改6381的配置 $ cp redis_6380.conf redis_6381.conf
启动
$ src/redis-server redis_6379.conf $ src/redis-server redis_6380.conf $ src/redis-server redis_6381.conf
测试复制
$ src/redis-cli -h 192.168.56.10 -p 6379 192.168.56.10:6379> set name pigfly OK 192.168.56.10:6379> quit $ src/redis-cli -h 192.168.56.10 -p 6380 192.168.56.10:6380> get name "pigfly" #复制成功 192.168.56.10:6380> quit $ src/redis-cli -h 192.168.56.10 -p 6379 192.168.56.10:6379> del name (integer) 1 192.168.56.10:6379> quit $ src/redis-cli -h 192.168.56.10 -p 6380 192.168.56.10:6380> get name (nil) #删除同步成功 192.168.56.10:6380> set age 23 #注意S只读，这是默认配置，如果要S可写修改read-only=no
#一般来说不建议这样做，因为复制的时候会把数据覆盖 (error) READONLY You can't write against a read only slave. 192.168.56.10:6380> quit $ src/redis-cli -h 192.168.56.10 -p 6379 192.168.56.10:6379> setex address 10 xxstreat OK 192.168.56.10:6379> quit $ src/redis-cli -h 192.168.56.10 -p 6380 192.168.56.10:6380> get address (nil) #过期同步成功
3.原理
当M和S连接正常时，redis通过命令传播来同步数据，每当M执行一个写命令，就会把命令发送给S，S执行后，两者达到数据的一致性。当S第一次连接或者断线后重连M的时候，复制过程是这样子的：
这个过程也可以称作是sync全量复制，每一次复制，M执行bgsave把所有数据打包成快照文件发给S，S再解包载入内存。
M执行bgsave消耗CPU、内存、磁盘I/O，传输过程消耗网络带宽，如果S是第一次连接M，不可避免会执行上述操作，但如果S是断线重连的情况，就有点不划算了，因为S真正需要复制的数据是断线以后的，如果全量复制就太浪费资源和时间了，所以redis2.8以后的版本做了改进，加了psync增量复制，psync（part-sync）跟sync不同的是，psync只发送S真正需要的命令流，大大地提高了打包和传输的效率，那么redis是怎么实现增量复制的呢？
replid, offset
每个M和S都有上面这两个属性，replid是M的唯一标识。offset是命令流的字节数，简单来说，只要有写入命令（就算没有S），这个offset就会增加
M维护着上图这样一个固定长度、先进先出的队列来保存最近的命令流
上图就是增量复制的过程，假定S当前offset=offset_s，M当前offset=offset_m：
1.M判断replid是否和自己的replid相等，如果不相等，跳出执行全量复制
2.M检查offset_s是否还在缓冲队列，如果是，发送从offset_s开始到offset_m的命令流，如果没有了，跳出执行全量复制
3.S执行命令流，更新offset_s = offset_m
复制的机制和特点：
当M和S连接良好时，S定时请求M进行复制，M向S发送命令流来保持同步 redis默认使用高性能的异步复制，S会异步向M确认收到的数据 当M和S由于网络问题或者超时导致断开连接，S会尝试重新连接，请求增量复制 不能增量复制时，执行全量复制 一个M可以有多个S S也可以复制其他S 复制在M端是非阻塞的，也就是M向S复制的过程中，M的查询不受影响 复制在S端也基本上是非阻塞的，初始化同步的时候，S可以提供旧数据来使查询不受影响，载入数据的时候，S将会阻塞连接不提供查询服务（非常大的数据也只需要短短几秒就同步完了），旧数据将会被删除，新数据将会被载入 可以把耗时查询放到S上面来提高主机的性能 可以使用复制来避免M持久化带来的开销，让一个S来持久化，但是应该避免M重启，因为M重启之后数据是空的，这时候如果同步的话S的数据也变成空了。就算是用redis的sentinel实现的高可用方案，也不要把持久化关了，说不定sentinel还没来得及检测到故障，M就已经宕机然后重启了。为了避免这种情况，建议M和S都打开持久化，下面就演示数据是如何丢失的： A,B,C三台redis服务器，A是M，B和C是S 因为某些原因，A宕机了，它执行自动重启机制，这时候因为关闭了持久化，磁盘里是没有备份数据的，内存里的数据也因为重启丢失了，所以重启之后数据全部丢了 B和C尝试同步，它们也不管A的数据是不是空，照常同步过来了，所以B和C的数据也丢了redis复制如何处理过期的缓存？ S不处理，而是等M处理过期后给S发送DEL命令 当M没有及时发送DEL命令，导致过期的缓存仍然存在于S，S将会根据自己的逻辑时钟报告缓存已过期，并且设置为只读 Lua脚本运行的时候，不执行缓存回收 一旦S变身为M，它马上自个儿执行缓存回收
使用Docker和NAT的情况，如何配置？
使用端口转发和网络地址转换的时候，redis复制要特别小心，特别是使用redis-sentiner，它是根据INFO命令来获取IP地址的，这种情况下可以配置IP端口映射，来让M获取到S正确的地址：
slave-announce-ip 5.5.5.5 slave-announce-port 1234
这样M执行INFO命令看到S的IP就是映射过的：
# Replication role:master connected_slaves:1 slave0:ip=5.5.5.5,port=1234,state=online,offset=420,lag=1
INFO命令
通过info命令可以查看复制的参数和状态
$ src/redis-cli -h 192.168.56.10 -p 6381 192.168.56.10:6381> info # Replication role:master connected_slaves:1 slave0:ip=192.168.56.10,port=6379,state=online,offset=644,lag=1 master_replid:b01608293384f8ea87b5bd0aabe081948f33a3dd master_replid2:0000000000000000000000000000000000000000 master_repl_offset:644 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:644
4.性能优化
1.调整缓冲队列的大小来尽可能达到增量复制而避免全量复制，repl-backlog-size默认1mb
5.参考资料
redis文档
redis实战
redis设计与实现