【Redis】Redis 主从复制之一

前言
  和关系型数据库一样，Redis也有自己的高可用属性，主从复制，相比而言 redis的主从复制的搭建过程更为简单。
一 redis 主从复制的特点
1 同一个master可以拥有多个slaves。
2 master下的Slave还可以接受同一架构中其它slave的链接与同步请求，实现数据的级联复制，即master->slave->Sslave模式；
3 master以非阻塞的方式同步数据至slave，这将意味着master会继续处理一个或多个slave的读写请求；
4 slave端同步数据也可以修改为非阻塞是的方式，当slave在执行新的同步时，它仍可以用旧的数据信息来提供查询；否则，当slave与master失去联系时，slave会返回一个错误给客户端；
5 redis的主从复制具有可扩展性，即多个slave专门提供只读查询与数据的冗余，master端专门提供写操作,实现读写分离，负载均衡；
6通过配置禁用Master数据持久化机制，将其数据持久化操作交给Slaves完成，避免在Master中要有独立的进程来完成此操作。

二 redis 复制的原理以及注意事项
 我们可以从slave redis 的log中查看redis 复制的主要过程

1. [3308] 24 May 23:09:44.133 * Connecting to MASTER 10.0.2.8:6379
   
2. [3308] 24 May 23:09:44.134 * MASTER <-> SLAVE sync started
   
3. [3308] 24 May 23:09:44.134 * Non blocking connect for SYNC fired the event.
   
4. [3308] 24 May 23:09:44.136 * Master replied to PING, replication can continue...
   
5. [3308] 24 May 23:09:44.137 * Partial resynchronization not possible (no cached master)
   
6. [3308] 24 May 23:09:44.137 * Full resync from master: 295a0c0dbf70e9b372ebdf6d14b0cae90072ac89:1
   
7. [3308] 24 May 23:09:44.143 * MASTER <-> SLAVE sync: receiving 40 bytes from master
   
8. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Flushing old data
   
9. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Loading DB in memory
   
10. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Finished with success
    
11. [3308] 24 May 23:24:44.033 * 1 changes in 900 seconds. Saving...
    
12. [3308] 24 May 23:24:44.034 * Background saving started by pid 3385
    
13. [3385] 24 May 23:24:44.037 * DB saved on disk
    
14. [3385] 24 May 23:24:44.038 * RDB: 0 MB of memory used by copy-on-write
    
15. [3308] 24 May 23:24:44.134 * Background saving terminated with success

结合redis 主从同步的日志和官方文档，我们总结一下redis的同步过程原理：
1 当一个redis 实例加上slaveof master_ip port 方式启动时，无论是第一次连接还是重连，它会主向master发送一个SYNC command，请求同步连接。
2 当master 收到SYNC 命令之后，发送一个PING 命令给slave ，且在后台执行bgsave命令，将数据快照保存到数据文件中，同时会记录所有修改数据的命令并缓存在数据文件。
3 master后台进程把数据持久化到磁盘之后，就发送数据库文件给slave。
4 slave端将数据文件保存到硬盘上，然后将其在加载到内存中，完成第一次全量同步操作。
5 master会将之前收集到的修改数据的操作和新的修改数据的操作发送给Slave端。
6 slave 收到这些命令之后会在本地执行，类似于MySQL的sql_thread操作。从而达到主从数据最终一致。
7 如果master和slave之间的链接出现断连，slave可以自动重连master。根据版本的不同，断连后同步的方式也不同：
    2.8之前：重连成功之后，一次全量同步操作将被自动执行.
    2.8之后：重连成功之后，进行部分同步操作.
Master持久化功能关闭时Replication的安全性
当我们部署redis主从复制的时候，一般都会强烈建议把master的持久化开关打开。即使为了避免持久化带来的延迟影响，不把持久化开关打开，那么也应该把master配置为不会自动启动的。因为master异常crash后再重启是非常危险的，会导致slave中的数据会被清空。
假设我们有一个redis节点A，设置为master，并且关闭持久化功能，另外两个节点B和C是它的slave，并从A复制数据。
如果A节点崩溃了导致所有的数据都丢失了，它会有重启系统来重启进程。但是由于持久化功能被关闭了，所以即使它重启了，它的数据集是空的。
而B和C依然会通过replication机制从A复制数据，所以B和C会从A那里复制到一份空的数据集，并用这份空的数据集将自己本身的非空的数据集替换掉。于是就相当于丢失了所有的数据。
即使使用一些HA工具，比如说sentinel来监控master-slaves集群，也会发生上述的情形，因为master可能崩溃后迅速恢复。速度太快而导致sentinel无法察觉到一个failure的发生。
部分同步(partial resynchronization )
这个特殊将会使用PSYNC 命令，注意该命令在2.8之后才支持PSYNC如果一个salve使用的是老的版本仅支持SYNC命令，那么将会用SYNC来同步
无磁盘的复制
通常一个同步需要在磁盘上创建一个RDB文件，然后再重新加载这个文件来进行与slave数据同步
由于磁盘的读写是非常慢的，这对于redis master是一个非常有压力的操作，在2.8.18之后的第一个版来尝试使用无磁盘的复制，在这个设置里了进程直接把RDB 发送到slaves,而不需要使用磁盘来做中间的存储。
需要注意的是 不过这个功能目前处于实验阶段，还未正式发布。
三  部署主从复制
环境 ：
rac4 主库 10.0.2.8:6379
rac3 从库 10.0.2.6:6379
1 在两台机器上或者同一台机器起不同的端口，具体步骤请参考《redis 初探》
2 修改rac3 的redis.cnf 添加配置 ，指向rac4
  slaveof 10.0.2.8 6379 
  也可以在rac3上启动redis之后执行
  slaveof 10.0.2.8 6379 
  不过一旦slave重启之后 主从关系就消失了。建议在redis.cnf 配置
3 启动主库和从库
  /usr/local/bin/redis-server /etc/redis/redis.conf
至此 搭建一个以rac4为主库 ，rac3为从库的redis 复制系统。
四 应用案例
主库

1. root@rac4:~# >redis-cli
   
2. 127.0.0.1:6379> select 0
   
3. OK
   
4. 127.0.0.1:6379> set name yangyi
   
5. OK
   
6. 127.0.0.1:6379> get name
   
7. "yangyi"
   
8. 127.0.0.1:6379>

从库

1. root@rac3:~# >redis-cli
   
2. 127.0.0.1:6379> select 0
   
3. OK
   
4. 127.0.0.1:6379> get name
   
5. "yangyi"
   
6. 127.0.0.1:6379>

五 推荐文章
    文章篇幅和时间有限，本文并未完整的介绍Redis的高可用特性，后续研究之后会陆续补充完整。 推荐《 redis replication官方介绍》，留一个(小白的)问题 ，redis主从复制过程和持久化的方式之间有什么关系吗 ，基于rdb 或者 aof的持久化 对主从复制有什么影响？