Redis主从复制、读写分离

前言

主从复制，即主机数据更新后根据配置和策略，自动同步到备机的master/slave机制，Master以写为主，Slave以读为主。主要用于读写分离和容灾恢复

一. 如何使用

1. “一主二仆”

1.1 修改配置文件

"一主二仆"是指一台主机，两台从机，咱们在虚拟机中模拟这三台机器（即让redis服务在三个不一样的端口运行），先拷贝两份redis配置文件，并重命名以便启动时区分

再在每份配置文件中修改以下配置项（此处以redis6380.conf为例）：

a). 指定端口（重要）

b). pidfile

c). logfile

d). dbfilename

e). 开启daemonize yes

*以上配置项按照配置文件不一样作相应修改

由于是在一台CentOS虚拟机上模拟了三个redis服务器，所以须要在开启客户端命令的后面加上端口号加以区别，不然默认会进入到6379端口的客户端。例如，要进入6380端口的客户端，使用命令

redis-cli -p 6380

三个客户端同时启动以下：

在6379端口Master主机输入info replication，能够查看主机与从机之间的链接状况

能够看到，如今6379端口的role是master，connected_slave如同其字面意思，表明链接上的从机，此时是0个。Slave从机在进行链接以前，输入info replication获得的结果和上面是同样的。

1.2 从机链接主机

在两个从机中使用以下命令，或者将以下命令写到配置文件中

slaveof <主机IP> <主机端口>

提示ok后，再在两个从机中输入info replication命令应该会获得以下结果：

此时，主机中info replication命令执行后获得

此时，主从链接就已经创建了。若是在主机中set了字段，两个从机会当即各自复制一份，保持和主机的数据同步，所以，在从机中也能够get到该字段的值。另外，从机会开启只读模式，里面的数据不能手动删除或更改，只能跟随主机中的数据的变化而变化。从机一旦链接上主机，就会把主机中全部数据都拷贝过来（并非只复制链接上主机后，主机中后来添加的数据）。

可是这里链接还可能遇到一些小问题，就是若是主机设置了链接校验密码（具体能够参看jedis初探的第三节），直接按照上面slaveof命令操做的话虽然也会返回ok，但实际上并无链接成功（能够自行用info replication命令测试），遇到这样的问题能够采用以下解决办法：

修改从机配置文件，将masterauth的注释取消，并将主机的链接校验密码填上，以下图

保存文件后，重启redis服务，再进行slaveof链接主机，就能够成功了。

1.3 总结

• 配从（库）不配主（库）
• 从库配置：slaveof 主库ip 主库端口（每次与master断开以后，都须要从新链接，除非你配置进redis.conf文件）
• 可使用info replication查看链接状况

2. “薪火相传”

2.1 什么意思

在上面的“一主二仆”中，是1台主机链接了2台从机，但实际状况中，主机链接的从机数量可能有多台，以下图，链接的从机数量越多，主机的负担越重

下图这种模式就是一种“去中心化”的模式，从机再也不是集中从Master复制数据，而是能够从其余从机中复制，减轻了主机的负担。以下图中slave2就是从slave1中复制的数据

所以，所谓的“薪火相传”指的是：上一个slave能够是下一个slave的master，slave一样能够接收其余slaves的链接和同步请求，该slave做为了链条中下一个的master，能够有效减轻master的写压力。

2.2  一个例子

6379端口的做为master机，6380端口的做为slave1，链接master，6381端口的做为slave2，链接slave1。链接图示和上面相同。链接成功后，master写入数据，slave1立刻就会复制一份，而slave2也会立刻从slave1中复制一份。此时，slave1的身份信息以下：

它虽然担当了slave2的master，但它自己仍是要从6379端口的master机中复制数据，因此它的role为slave，同时，由于slave2连在它身上，因此connected_slaves显示链接的从机数为1。

这种“薪火相传”的使用方法也很简单，slave2以前链接的是6379端口的master，如今要改链接到6380端口的slave1，只须要使用以下命令：

slaveof 127.0.0.1 6380
#slaveof <从机ip> <从机端口>

须要注意的是：中途变动转向，会清除以前的数据，从新创建拷贝最新的。什么意思呢？slave2原来链接的是6379端口的master，其数据库中就有master机的所有数据，改变链接后，就会删除这些数据，从新创建对slave1的数据拷贝

3. “反客为主”

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

使用命令：slaveof no one

举个例子：

在上图的主从关系中，若是master主机忽然“挂了”，这时，slave1和slave2所采起的操做是“原地待命”，一直等待master从新回来。此时，能够在一个从机中使用slaveof no one 命令，让从机变成主机，继续担当master的任务。这时，其余从机能够转链接到该主机上，从新组成一个主从体系。

4. 使用jedis进行主从复制

可是程序执行中可能出现下面这种状况：

结果为null值，这里并非程序出了什么错，而是内存数据库太快了，致使没有取到值（程序慢于内存，redis中已经有值了，而程序还没取到）。若是你在redis客户端使用get命令（或者再运行一遍程序），就会发现实际上是有值的。

注意：主从的配置（slaveof）通常不在代码中控制，而是由架构/技术经理规定好主从关系，并在后台使用unix命令配好，开发人员须要关注的是谁是主谁是从，以及主从的读写操做便可。

二. 复制原理

1. Slave启动成功链接到master后会发送一个sync命令
2. Master接到命令启动后台的存盘进程，同时收集全部接收到的用于修改数据集的命令， 在后台进程执行完毕以后，master将传送整个数据文件到slave,以完成一次彻底同步
3. 全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
4. 增量复制：Master继续将新的全部收集到的修改命令依次传给slave,完成同步。
5. 只要是从新链接master,一次彻底同步（全量复制）将被自动执行。首次是全量复制，以后是增量复制。

三. 复制的缺点

复制延时：因为全部写操做都是先在master上操做，而后同步更新到slave上，因此从master同步到slave机器有必定的延迟，当系统很繁忙的时候，延迟问题会更加严重。slave机器数量的增长也会使这个问题更加严重

 

四. 哨兵模式（经常使用）

1. 是什么

哨兵巡逻，可以后台监控主机是否故障，若主机发生故障就会自动在剩余的从机中经过投票的方式选出新的主机，并自动进行切换。简单来讲是上面“反客为主”的自动版，可是也有些不一样的地方。

2. 使用步骤

2.1 在redis安装目录下新建sentinel.conf文件，名字绝对不能错

2.2 配置哨兵，填写内容。在sentinel.conf中填写以下内容

sentinel monitor 被监控的主机的名字（名字本身起）127.0.0.1 6379 1
#上面最后一个数字1，表示最低经过票数（主机挂掉后投票看让谁接替成为主机）

2.3 启动哨兵

如上图所示，咱们须要用到redis/bin目录下的redis-sentinel工具，启动时还须要带上咱们刚才设置的配置文件，启动命令及启动效果以下：

3. 遇到的问题

学习过程当中遇到主机挂掉后，哨兵自动切换出现故障的问题，具体表现为：主机挂掉后，从新启动链接不上新的主机；且有的时候，从机也连不上新的主机。为此十分苦恼，在查阅了相关资料并进行了一些试验后发现，原来是由于个人redis是设置了校验密码的，这里的配置中须要增长一些内容，具体以下：

1). 在哨兵的配置文件sentinel.conf中，增长主机校验密码，改为以下内容：

sentinel monitor mymaster 127.0.0.1 6381 1
sentinel auth-pass mymaster 123456  #增长主机校验密码

2). 在redis配置文件中（包括主机和从机），都添加requirepass和masterauth配置

requirepass "123456"
masterauth "123456"

须要注意的是，主机从机都尽可能设置同样的密码！而且主机中要添加masterauth，这点很容易被忽略，由于主机在挂掉后从新启动，它将做为从机去链接新的主机，若是没有这项就会致使链接不上新的主机。

在这个过程当中，哨兵日志是“滞后”的，好比有时候从新启动主机，查看其info replication显示它链接的是另外一个从机而不是新主机，且链接状态是down，过一下子，日志中才更新消息，将其链接改成链接到新主机

五. 参考资料

http://www.javashuo.com/article/p-udkxqvam-cb.html（redis哨兵配置详解）

http://blog.csdn.net/a67474506/article/details/50435498（解读redis哨兵日志内容）