Redis的复制(Master/Slave)

Redis虽然有着卓越的性能，但我们仍然可以通过master/slave这种简单架构，进行读写分离，进一步挖掘redis的性能，提高系统的可用性。

redis怎么进行主从复制呢？redis复制主要是通过master server持久化的rdb文件实现的。master server 先dump出内存快照文件，然后将rdb文件传给slave server，slave server 根据rdb文件重建内存表。redis复制过程如下：

1、slave server启动连接到master server之后，salve server主动发送SYNC命令给master server

 2、master server接受SYNC命令之后，判断，是否有正在进行内存快照的子进程，如果有，则等待其结束，否则，fork一个子进程，子进程把内存数据保存为文件，并发送给slave server

3、master server子进程进程做数据快照时，父进程可以继续接收client端请求写数据，此时，父进程把新写入的数据放到待发送缓存队列中

4、slave server 接收内存快照文件之后，清空内存数据，根据接收的快照文件，重建内存表数据结构

5、master server把快照文件发送完毕之后，发送缓存队列中保存的子进程快照期间改变的数据给slave server，slave server做相同处理，保存数据一致性

6、master server 后续接收的数据，都会通过步骤1建立的连接，把数据发送到slave server

需要注意：slave server如果因为网络或其他原因断与master server的连接，当slave server重新连接时，需要重新获取master server的内存快照文件，slave server的数据会自动全部清空，然后再重新建立内存表，这样会让slave server 启动恢复服务比较慢，同时也给master server带来较大压力，可以看出redis的复制没有增量复制的概念，这是redis主从复制的一个主要弊端，在实际环境中，尽量规避中途增加从库

1.是什么

行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

2.能干嘛

读写分离

容灾恢复

3.配置

原文 http://blog.csdn.net/love__coder/article/details/8679198

master server 配置文件master.conf， 主要配置如下：

1. daemonize yes  
2. pidfile /var/run/redis_6379.pid  
3. port 6379  
4. #save 900 1  
5. #save 300 10  
6. #save 60 10000  
7. dbfilename dump.rdb  
8. dir /var/lib/redis/6379  

slave server 配置文件redis80.conf，主要配置如下：

1. daemonize yes  
2. pidfile /var/run/redis_6379.pid  
3. port 6380  
4. save 900 1  
5. save 300 10  
6. save 60 10000  
7. dbfilename dump.rdb  
8. dir /var/lib/redis/6380  
9. slaveof 127.0.0.1 6379 
   

从库配置：slaveof 主库IP 主库端口

如果不配置slaveof 127.0.0.1 6379 

每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件

slave.conf中，主要通过slaveof指定其master的ip和端口。启动master和slave：

1. /usr/local/bin/redis-server /etc/redis/master.conf 
   

1. /usr/local/bin/redis-server /etc/redis/redis80.conf 
   

连接master server，写入数据：

1. [root@xsf001 ~]# redis-cli -p 6379  
2. redis 127.0.0.1:6379> set user.1.name zhangsan  
3. OK 
   

连接 slave server，读数据：

1. [root@xsf001 ~]# redis-cli -p 6380  
2. redis 127.0.0.1:6380> get user.1.name  
3. "zhangsan"  

从测试结果看，数据确实自动复制了。通过复制功能，我们可以在master上只写数据，在slave上读数据，关闭master的持久化（或aof）功能（在salve上开启），从而分担master服务器读压力，提高master服务器性能，同时，master挂了，可以快速地用slave server来替换master server，提高系统的可用性。

测试：

主从复制

从库只能读

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他

slaves的连接和同步请求，那么该slave作为了链条中下一个的master,

可以有效减轻master的写压力

中途变更转向:会清除之前的数据，重新建立拷贝最新的  slaveof 新主库IP 新主库端口

反客为主

使当前数据库停止与其他数据库的同步，转成主数据库

SLAVEOF no one

复制原理

slave启动成功连接到master后会发送一个sync命令

Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，
在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步

4.哨兵模式(sentinel)

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

redis哨兵配置主从

redis哨兵的启动和redis实例的启动没有关系。所以可以在任何机器上启动redis哨兵。至少要保证有两个哨兵在运行，要不然宕机后哨兵会找不到主节点。

配置步骤：

1.在redis的配置文件中添加鉴权和验证（添加requirepass和masterauth），redis主从都需要配置，配置的密码一般相同。

2.redis一般都在内网运行，所以注释掉#bind 127.0.0.1

3.关闭保护模式，protected-mode 把yes改为no

4.添加sentinel.conf配置文件：

#sentinel端口port 26379#工作路径，注意路径不要和主重复dir "/usr/local/redis-6379"# 守护进程模式daemonize yes#关闭保护模式protected-mode no# 指明日志文件名logfile "./sentinel.log"#哨兵监控的master，主从配置一样，这里只用输入redis主节点的ip/port和法定人数。sentinel monitor mymaster 192.168.125.128 6379 1# master或slave多长时间（默认30秒）不能使用后标记为s_down状态。sentinel down-after-milliseconds mymaster 5000#若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。sentinel failover-timeout mymaster 18000#设置master和slaves验证密码sentinel auth-pass mymaster 123456 sentinel parallel-syncs mymaster 1//指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步

Sentinel参数在运行时可以使用SENTINEL SET命令更改

上面配置中的mymaster为该主从的名字，代码中会使用。

通过哨兵查看集群的信息：

$ redis-cli -p 26379sentinel master mymaster//查看master的状态 SENTINEL slaves mymaster //查看salves的状态SENTINEL sentinels mymaster //查看哨兵的状态SENTINEL get-master-addr-by-name mymaster//获取当前master的地址info sentinel//查看哨兵信息

启动哨兵：

方式一：redis-sentinel /path/to/sentinel.conf（推荐，这种方式启动和redis实例没有任何关系）方式二：redis-server /path/to/sentinel.conf --sentinel

一组sentinel能同时监控多个Master

5.复制的缺点：复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。