Redis 主从同步
主从同步也称作主从复制，一般由最少3台 Redis 服务器节点组成，其中包括一个主节点（master）以及多个从节点（slave），也就是一主多从的模式。在一定的时机下，从节点会去同步主节点的数据。实现了主从同步的结构后，一方面可以备份数据，保证了数据的安全性；一般情况下，主节点负责数据的写入操作，从节点负责数据的读取操作，可以实现读写分离，减小主节点的压力；当然也提高了 Redis 服务的可用性，某个节点宕机了其它节点可以继续工作。
一、主从同步配置
下边我们采用一个主节点两个从节点的结构来配置 Redis 的主从同步，这里使用 win10 的 Ubuntu 客户端，启动三个 Redis 来模拟运行环境。具体的操作和在 CentOS 上都是类似的。
首先重新命名 Redis 配置文件，方便区分三个节点。将redis.conf重命名为redis6379.conf，作为主节点配置文件，再复制两份分别命名为redis6380.conf、redis6381.conf，做为两个从节点的配置文件。
我们约定6379为主节点，6380``6381分别是6379的从节点，对配置文件分别做如下修改：
# redis6379.conf
port 6379
pidfile /var/run/redis_6379.pid
logfile "/usr/local/redis/log/redis_6379.log"
masterauth shehuan
dbfilename dump_6979.rdb
appendfilename "appendonly_6379.aof"
# redis6380.conf
port 6380
pidfile /var/run/redis_6380.pid
logfile "/usr/local/redis/log/redis_6380.log"
masterauth shehuan
dbfilename dump_6980.rdb
appendfilename "appendonly_6380.aof"
# redis6381.conf
port 6381
pidfile /var/run/redis_6381.pid
logfile "/usr/local/redis/log/redis_6381.log"
masterauth shehuan
dbfilename dump_6981.rdb
appendfilename "appendonly_6381.aof"
节点都配置了masterauth shehuan，就是连接节点的密码，因为各个 Redis 服务器都配置了连接密码。由于这里是模拟三个节点，所以需要修改这些端口相关的配置，真实环境肯定是在不同的服务器，自然也就不需要了。
现在分别启动三个节点：
默认都是主节点，接下里就是配置节点之间的主从关系了，分别打开6380、6381的 Redis 客户端，执行如下命令：
bin/redis-cli -p 6380 -a shehuan
slaveof 127.0.0.1 6379
bin/redis-cli -p 6381 -a shehuan
slaveof 127.0.0.1 6379
这样，6379就有了两个从节点，通过info replication命令查看主节点状态：
顺便看一下从节点的状态：
到这里基本的配置就结束了。
按照上边的配置我们的主从结构应该是这样的：
我们也可以让6381成为6380的从节点：
bin/redis-cli -p 6381 -a shehuan
slaveof 127.0.0.1 6380
此时主从结构是这样的：
二、测试
现在可以做一个简单测试，我们在主节点存一条数据，然后在从节点查看数据是否同步过来了：
结果符合预期，也可以先只启动主节点并写入数据，然后启动从节点，数据依然可以同步过去。
三、主从同步原理
Redis 主从同步可以分为数据的全量同步和增量同步两种。
-
全量同步，一般发生在从节点启动后连接到主节点时，只要连接一次就会发生一次全量同步，大致的步骤如下：
1、从节点启动后连接到主节点，会给主节点发送一个 sync 命令请求同步数据
2、主节点收到命令后，进行 RDB 快照持久化，并开始用缓冲区记录后续的写命令。快照持久化完成后，将快照文件发送给从节点
3、从节点收到快照文件后，会丢弃掉旧的数据，然后加载收到的快照文件
4、主节点发送完快照文件后，开始发送缓冲区的写命令给从节点
5、从节点加载完了快照文件，开始接收并执行写命令，到这里一次全量同步完成 -
增量同步，完成了全量同步，相当于从节点已经初始化结束，开始正式工作。此后开始增量同步：
1、主节点上每执行一个写命令，就会给从节点发送同样的命令
2、从节点会接收并执行写命令，完成一次增量同步
四、哨兵模式
按照我们上边配置，如果主节点宕机了，就只剩从节点了，就需要重启主节点或者手动将一个从节点指定为主节点，而无法自动的在从节点中选出一个新的主节点，需要人工干预。
这个问题可以使用哨兵模式来解决。
哨兵是一个独立的进程，默认在前台启动，需要改为后台启动，哨兵的配置文件是sentinel.conf，主要的配置如下：
# 后台启动
daemonize yes
# 连接哨兵的密码
# requirepass shehuan
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel auth-pass mymaster shehuan
logfile "/usr/local/redis/log/sentinel.log"
第一条配置中，mymaster表示要监控的主节点名称，可以随便写，接下来是主节点的地址，最后的数字表示有多少个哨兵监控到主节点宕机了，就进行新的主节点选举，这简单一些，只配置 1 个哨兵。
先启动好上边的三个节点，然后启动哨兵：
bin/redis-sentinel conf/sentinel.conf
启动成功后查看日志，已经开始监控主节点：
哨兵通过发送命令，等待主节点响应，默认当哨兵30秒都收不到主节点响应时，就任务主节点宕机了，会开始重新选举一个主节点。
这里手动关闭6379主节点，然后观察哨兵日志：
最终选举出6380为主节点。即便再重启6379，它也将变成6380的从节点：
这里只是哨兵模式的简单实用，更多复杂的用法可以自行探索。
