redis主从复制

参考链接：https://www.cnblogs.com/lukexwang/p/4711977.html

一、主从**
在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库[1] （slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

Redis的replication机制允许slave从master那里通过网络传输拷贝到完整的数据备份。具有以下特点：

1. 异步复制。从2.8版本开始，slave能不时地从master那里获取到数据。 允许单个master配置多个slave

2. slave允许其它slave连接到自己。一个slave除了可以连接master外，它还可以连接其它的slave。形成一个图状的架构。

3. master在进行replication时是非阻塞的，这意味着在replication期间，master依然能够处理客户端的请求。

4. slave在replication期间也是非阻塞的，也可以接受来自客户端的请求，但是它用的是之前的旧数据。可以通过配置来决定slave是否在进行replication时用旧数据响应客户端的请求，如果配置为否，那么slave将会返回一个错误消息给客户端。不过当新的数据接收完全后，必须将新数据与旧数据替换，即删除旧数据，在替换数据的这个时间窗口内，slave将会拒绝客户端的请求和连接。

5. 一般使用replication来可以实现扩展性，例如说，可以将多个slave配置为“只读”，或者是纯粹的数据冗余备份。

6. 能够通过replication来避免master每次持久化时都将整个数据集持久化到硬盘中。只需把master配置为不进行save操作(把配置文件中save相关的配置项注释掉即可)，然后连接上一个slave，这个slave则被配置为不时地进行save操作的。不过需要注意的是，在这个用例中，必须确保master不会自动启动

Master持久化功能关闭时Replication的安全性
当有需要使用到replication机制时，一般都会强烈建议把master的持久化开关打开。即使为了避免持久化带来的延迟影响，不把持久化开关打开，那么也应该把master配置为不会自动启动的。

为了更好地理解当一个不进行持久化的master如果允许自动启动所带来的危险性。可以看看下面这种失败情形：

假设我们有一个redis节点A，设置为master，并且关闭持久化功能，另外两个节点B和C是它的slave，并从A复制数据。
如果A节点崩溃了导致所有的数据都丢失了，它会有重启系统来重启进程。但是由于持久化功能被关闭了，所以即使它重启了，它的数据集是空的。
而B和C依然会通过replication机制从A复制数据，所以B和C会从A那里复制到一份空的数据集，并用这份空的数据集将自己本身的非空的数据集替换掉。于是就相当于丢失了所有的数据。
即使使用一些HA工具，比如说sentinel来监控master-slaves集群，也会发生上述的情形，因为master可能崩溃后迅速恢复。速度太快而导致sentinel无法察觉到一个failure的发生。

当数据的安全很重要、持久化开关被关闭并且有replication发生的时候，那么应该禁止实例的自启动。

replication工作原理
当从数据库启动时，会向主数据库发送sync命令，主数据库接收到sync后开始在后台报错快照rdb，在保存快照期间受到的命名缓存起来，当快照完成时，主数据库会将快照和缓存的命令一块发送给从。复制初始化结束。
之后，主每受到1个命令就同步发送给从。
当出现断开重连后，2.8之后的版本会将断线期间的命令传给重数据库。增量复制

主从复制是乐观复制，当客户端发送写执行给主，主执行完立即将结果返回客户端，并异步的把命令发送给从，从而不影响性能。也可以设置至少同步给多少个从主才可写。

数据部分复制
从2.8版本开始，slave与master能够在网络连接断开重连后只进行部分数据复制。

master会在其内存中创建一个复制流的等待队列，master和它所有的slave都维护了复制的数据下标和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。如果进程id变化了，或者数据下标不可用，那么将会进行一次全部数据的复制。
支持部分数据复制的命令是PSYNC

不需硬盘参与的Replication
一般情况下，一次复制需要将内存的数据写到硬盘中，再将数据从硬盘读进内存，再发送给slave。

对于速度比较慢的硬盘，这个操作会给master带来性能上的损失。Redis2.8版本开始，实验性地加上了无硬盘复制的功能。repl-diskless-sync yes

相关配置
与replication相关的配置比较简单，只需要把下面一行加到slave的配置文件中：

slaveof 192.168.1.1 6379
你只需要把ip地址和端口号改一下。当然，你也可以通过客户端发送SLAVEOF命令给slave。

部分数据复制有一些可调的配置参数，请参考redis.conf文件。

无硬盘复制功能可以通过repl-diskless-sync来配置，另外一个配置项repl-diskless-sync-delay用来配置当收到第一个请求时，等待多个slave一起来请求之间的间隔时间。

只读的slave
从redis2.6版本开始，slave支持只读模式，而且是默认的。可以通过配置项slave-read-only来进行配置，并且支持客户端使用CONFIG SET命令来动态修改配置。

只读的slave会拒绝所有的写请求，只读的slave并不是为了防范不可信的客户端，毕竟一些管理命令例如DEBUG和CONFIG在只读模式下还是可以使用的。如果确实要确保安全性，那么可以在配置文件中将一些命令重新命名。

也许你会感到很奇怪，为什么能够将一个只读模式的slave恢复为可写的呢，尽管可写，但是只要slave一同步master的数据，就会丢失那些写在slave的数据。不过还是有一些合法的应用场景需要存储瞬时数据会用到这个特性。不过，之后可能会考虑废除掉这个特性。

Setting a slave to authenticate to a master

如果master通过requirepass配置项设置了密码，slave每次同步操作都需要验证密码，可以通过在slave的配置文件中添加以下配置项：

masterauth
也可以通过客户端在运行时发送以下命令：

config set masterauth

至少N个slave才允许向master写数据
从redis2.8版本开始，master可以被配置为，只有当master当前有至少N个slave连接着的时候才接受写数据的请求。

然而，由于redis是异步复制的，所以它并不能保证slave会受到一个写请求，所以总有一个数据丢失的时间窗口存在。

这个机制的工作原理如下所示：

1. slave每秒发送ping心跳给master，询问当前复制了多少数据。
2. master会记录下它上次收到某个slave的ping心跳是什么时候。
3. 使用者可以配置一个时间，来指定ping心跳的发送不应超过的一个超时时间
4. 如果master有至少N个slave，并且ping心跳的超时不超过M秒，那么它就会接收写请求。

也许你会认为这情形好似CAP理论中弱化版的C(consistency)，因为写请求并不能保证数据的一致性，但这样做，至少数据丢失被限制在了限定的时间内。即M秒。

如果N和M的条件都无法达到，那么master会回复一个错误信息。写请求也不会被处理。

有两个配置项用来配置上文中提到的N和M：

min-slaves-to-write 
min-slaves-max-lag 

如果需要了解更多，请查阅redis.conf配置文件。