redis（6）、redis复制
redis技术目录
一、redis复制介绍
（1）什么是redis复制
redis复制即redis replication，主要用于主从(master-slave)数据复制异步备份，或者读写(read-write)分离。使用和配置起来非常简单，从redis服务器会复制并且保存主redis服务器的数据，从而达到备份需求或者同步数据之后，其他客户端读分离的需求。
而常用的redis复制使用方案
a)、读写分离简要图示：
适用场景：适用于数据量不是非常大，单机的数据复制到相同的多台服务器，多台的服务器数据相同，从而达到读写分离，负债均衡的作用。事实上，稍微性能强悍点的物理单机，足以应对大部分的系统了，我们需要做的要主从备份，防止数据意外丢失。
缺点：有可能从服务器的数据会稍微延迟于主redis。
b）、主从备份、自动切换的简要图示
适用场景：如果主redis服务器崩溃或则其他原因不可用，要求服务不可停用，从而需要redis自动切换。如果不需要自动切换，主redis挂了之后，手动切换到从redis也是较为保险的方案。
缺点：同读写分类一样，也是从服务器的数据会稍微延迟于主redis。
二、使用redis 复制
（1）、配置很简单，主服务器上不需要任何额外配置，正常启动
（2）、从服务器需要添加一行命令（仅此一行）slaveof <masterip> <masterport>
（3）、如果主服务器上开启了密码验证（主服务器不要bind 127.0.0.1，否则其他服务器怎么也不能复制数据，就算绑定，把从服务器的ip也绑定了），
那就在从服务器上在加一行masterauth <master-password>。收工。
当然了，关于redis复制配置命令，还有一些额外的命令：
slave-serve-stale-data yes|no | 当slave和master之间的连接断开或slave正在于master同步时，如果有slave请求，当slave-serve-stale-data配置为yes时，slave可以相应客户端请求；当为no时，slave将要响应错误，默认是yes |
slave-read-only yes|no | 从服务器是否只读。设置为no时，可以接受客户端写命令，事实上从服务器写指令之后并不会同步到主服务器，而从服务器会周期性的同步主服务器的数据，很有可能这个写的数据会丢失。因为redis设置复制时，就没有考虑master-master这种架构。这个命令纯属鸡肋，并没有什么卵用。默认是yes |
repl-diskless-sync yes|no | 复制集同步策略：磁盘或者socket 当新slave连接或者老slave重新连接时候不能只接收不同，得做一个全同步。需要一个新的RDB文件dump出来，然后从master传到slave。可以有两种情况： （1）、基于硬盘（disk-backed）：master创建一个新进程dump RDB，然后由父进程（即主进程）增量传给slaves。 （2）、基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。 使用建议： （1）、基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的 slave。基于socket的话， 新slave来了后，得排队（如果超出了repl-diskless-sync-delay还没来），结束一个再进行下一个。如果一个主多个从，强烈建议使用基于硬盘的方案。 （2）、当用diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了。否则就可以一起传。 （3）、disk较慢，并且网络较快的时候，可以用diskless。（默认用disk-based） ps：配置高性能的硬盘，使用默认基于硬盘即可，这样节省网络。 默认为no |
repl-diskless-sync-delay 5 | 设置成0的话，传输开始立马进行下一个。 默认为5。 |
repl-ping-slave-period 10 | Slave发送ping给master。默认10s |
repl-timeout 60 | 超时时间，包括从master看slave，从slave看master，要大于上边的repl-ping-slave-period |
repl-disable-tcp-nodelay no | SYNC完毕后，在slave的socket里关闭TCP_NODELAY。 如果是yes,reids发送少量的TCP包给slave，但可能导致最高40ms的数据延迟。 如果是no，那可能在复制的时候，会消耗 少量带宽。 默认我们是为了低延迟优化而设置成no，如果主从之间有很多网络跳跃。那设置成yes吧。 |
repl-backlog-size 1mb | 复制集后台backlog大小，越大，slave可以丢失的时间就越长。 |
repl-backlog-ttl 3600 | 多久释放backlog，当确认master不再需要slave的时候，多久释放。0是永远不释放。 |
slave-priority 100 | 当master不可用，Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。而配置成0，永远不会被选举。（必须≥0）。默认是100。可以在配置集群时使用。 |
min-slaves-to-write 3 min-slaves-max-lag 10 | slave小于几个，网络lag大于几秒的时候，master停止接受write请求。默认对slave数目无限制，给0。网络延迟给10s |
三、redis特性
（1）、Redis采用异步复制。从Redis 2.8开始，从服务器会每隔一段时间循环复制流（主服务器待复制的数据）的数据，从而进行复制处理。
（2）、一个主服务器可以连接多个从服务器。
（3）、从服务器可以接受其他从服务器的连接。
（4）、Redis的复制在主服务器上是非阻塞的。redis 主服务器会fork出一个子进程去处理复制业务，这样正是因为redis服务器不能设置maxmemory为服务器的全部内存的原因之一。
（2）、一个主服务器可以连接多个从服务器。
（3）、从服务器可以接受其他从服务器的连接。
（4）、Redis的复制在主服务器上是非阻塞的。redis 主服务器会fork出一个子进程去处理复制业务，这样正是因为redis服务器不能设置maxmemory为服务器的全部内存的原因之一。
也意味着，当一个或多个从服务器执行初始化同步(initial synchronization)时，主服务器能继续处理请求。
（5）、Redis的复制在从服务器上也是非阻塞的。
（6）、复制可以用来支持可伸缩性，用多个从服务器处理只读查询(例如，繁重的SORT操作可以分配到从服务器上)，也可以仅仅作为数据冗余。
（5）、Redis的复制在从服务器上也是非阻塞的。
（6）、复制可以用来支持可伸缩性，用多个从服务器处理只读查询(例如，繁重的SORT操作可以分配到从服务器上)，也可以仅仅作为数据冗余。
四、redis复制原理
（1）、当你建立一个从服务器，连接时就会发送一个SYNC命令。不管是第一次连接上还是重连接上。 然后主服务器开始在后台保存，并且开始缓冲所有新收到的会修改数据集的命令。当后台保存完成以后，主服务器传输数据库文件给从服务器，从服务器将其保存到磁盘上，然后加载到内存中。然后主服务器开始发送缓冲的命令给从服务器。这是通过命令流完成的，和Redis的协议是一样的格式。
（2）、当主从链路由于某些原因断开时，从服务器可以自动重连。如果主服务器收到多个并发的从服务器的同步请求，只会执行一个后台保存来服务所有从服务器。
当主服务器和从服务器断开后重连上，总是执行一次完整重同步(full resynchronization)。然而，从Redis 2.8以后，可以选择执行部分重同步(partial resynchronization)。
（3）、从Redis 2.8开始，在复制链接断开后，主服务器和从服务器通常可以继续复制过程，而不需要一次完整的重同步。
这是通过在主服务器上创建一个复制流的内存缓冲区(in-memory backlog)实现的。主服务器和所有从服务器都记录一个复制偏移量(offset)和一个主服务器运行ID(run id)，当链接断掉时，从服务器会重连接，并且请求主服务器继续复制。假设主服务器的运行ID还是一样的，并且指定的偏移量在复制缓冲区中可用，复制会从中断的点继续。如果这两个条件之一不满足，将会执行完整重同步(2.8版之前的正常行为)。
新的部分重同步特性使用的是内部PSYNC命令，老的实现采用的是SYNC命令。注意，Redis 2.8的从服务器可以检测主服务器是否不支持PSYNC，然后使用SYNC代替。
新的部分重同步特性使用的是内部PSYNC命令，老的实现采用的是SYNC命令。注意，Redis 2.8的从服务器可以检测主服务器是否不支持PSYNC，然后使用SYNC代替。
复制原理简图：
五、小结
在实际生产中，多数系统使用主从配置即可达到大部分的系统性能要求，如果要求主从自动切换，使用类似keepalived就足以满足需求了。
相关推荐
pigsmall 2020-11-19
graseed 2020-10-28
大数据杂谈 2020-09-26
SXIAOYI 2020-09-16
jinhao 2020-09-07
ChinaWin 2020-08-13
mohanzb 2020-08-01
王国平 2020-06-20
yoohsummer 2020-06-01
kangtingting0 2020-05-20
MichelinMessi 2020-02-19
impress 2020-02-20
nicepainkiller 2020-01-25
hfszy0 2013-05-15
lizhenmxcz 2013-05-12
gxyblue 2013-05-11
chenshuixian 2013-06-01
羽化大刀Chrome 2013-05-31
tichangde 2020-01-17