A, Redis master copy from
1.1, master-slave replication Introduction
1) the use of asynchronous replication.
2) a plurality of master server from the server. From the server can also have its own from the server.
3) Copy function does not block the main server
4) You can make from the primary server to perform persistence operations by the copy function, the operation can be executed from the server to persist .
1.2 Data Security
When configuring Redis replication, it is strongly recommended to open a persistent feature of the master server. Otherwise, due to delays and other problems, the deployment of services should be avoided automatically pull up . To help understand the risk automatically pull up the home server is down persist, refer to the following example will lead to master all of the lost data from the server:
1. Assuming the main server node A, and turn off persistence. And nodes B and C to copy the data from node A
2. A node crashes, and then restart automatically pulled from the service node A. Since the node A persistence was closed, so there is no data after a reboot
3. nodes B and C from node A copy data, but the data A is empty, so he took a copy of the data stored by the deletion.
4) in the closing of the main server persistence, and at the same time open the case automatically pull up the process, even with Redis Sentinel to achieve high availability, but also very dangerous. Because the primary server may be pulled up very quickly, so that the master is not detected Sentinel server has been restarted, then the above would be executed in the process data loss heartbeat configured time interval.
Whenever data security is extremely important, so at the same time should be banned persistent primary server goes down automatically pull up .
1.3, copy the master-slave principle
Rationale :
1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从临时断开。从库数据没有被破坏的情况下，在下次重连之后，，从库发送PSYNC给主库 (2.8版本之后)
9. 主库只会将从库缺失部分的数据同步给从库应用，达到快速恢复主从的目的
其他说明：
1）SYNC 命令执行示例
2）命令传播
在主从服务器完成同步之后，主服务器每执行一个写命令，它都会将被执行的写命令发送给从服务器执行，这个操作被称为“命令传播”（command propagate）。命令传播是一个持续的过程：只要复制仍在继续，命令传播就会一直进行，使得主从服务器的状态可以一直保持一致
3）复制中的SYNC与PSYNC
①在 Redis 2.8 版本之前， 断线之后重连的从服务器总要执行一次完整重同步（full resynchronization）操作。
②从 Redis 2.8 开始，Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步（partial resync）特性：在主从服务器断线并且重新连接的时候，只要条件允许，PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。
SYNC 处理断线重连示例：
PSYNC 处理断线重连示例：
1.4、复制一致性
1.4.1、问题引出
1）在读写分离环境下，客户端向主服务器发送写命令 SET n 10086，主服务器在执行这个写命令之后，向客户端返回回复，并将这个写命令传播给从服务器。
2）接到回复的客户端继续向从服务器发送读命令 GET n ，并且因为网络状态的原因，客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。
3）因为从服务器键 n 的值还未被更新，所以客户端在从服务器读取到的将是一个错误（过期）的 n值。
1.4.2、问题解决
从 Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到，因此， 数据丢失的可能性仍然是存在的。
通过以下两个参数保证数据的安全：
slaves-to--min Write <Number of slaves> min-max-LAG-slaves <Number of seconds The> principle of operation of this feature: the server once a second PING master once, and report the case of the copy processing flow . Master server will record the time each time it is sent from the server to PING last. 1) You can configure, specify the maximum network delay min-slaves-max-lag, and the number of operations required to write server min-slaves-to-write at least from. If at least min-slaves-to-write to it from the server, and the server delay values are less than the min-slaves-max-lag seconds, then the master will perform a write operation requested by the client. 2) On the other hand, if the conditions fail min-slaves-to-write and min-slaves-max-lag specified condition, the write operation will not be executed, the write operation to the main server request to execute the client It returns an error.