redis主从复制、哨兵机制和集群

1、复制（master-slave）
配置过程 修改 slave机器的 redis.conf 增加如下配置
slaveof
我这里两台slave 都配置
slaveof 192.168.159.10 6379
重启三台reidis 服务后 启动
执行 ./redis-cli 链接 本机redis 服务 然后执行info replication 可以看到主从状态信息如下
master：

[root@192 bin]# ./redis-cli 
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.159.12,port=6379,state=online,offset=99,lag=1
slave1:ip=192.168.159.11,port=6379,state=online,offset=99,lag=1
master_repl_offset:99
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:98

slave ：

[root@192 bin]# ./redis-cli 
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.159.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:99
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

然后在主节点自行 set name zhang 从节点执行 get name 也是zhang
并且从节点默认不能进行写操作。执行 set name zhang 报错如下(redis.conf 中有默认配置 slave-read-only yes)：

127.0.0.1:6379> set name zhang
(error) READONLY You can't write against a read only slave.
127.0.0.1:6379> get name

实现原理 ：
1）slave第一次或重新连接到master 后 会向master发送一个sunc 命令
2）master收到sync 的时候做两件事
a）执行bgsave rdb快照保存数据到磁盘 并把文件传送给salve，slave收到文件会把文件中的数据加载到内存
b）把新收到的修改命令保存到缓冲区，并将命令发送给slave 实现同步
验证同步操作。
在slave几点执行sync 可以看到 命令同步过程如下：
主几点执行 set name li 后 slave 收到了 set name li

127.0.0.1:6379> sync
Entering slave output mode...  (press Ctrl-C to quit)
SYNC with master, discarding 42 bytes of bulk transfer...
SYNC done. Logging commands from master.
"PING"
"PING"
"PING"
"PING"
"PING"
"SELECT","0"
"set","name","li"

主从数据不一致问题解决：
redis.conf 中 slave-serve-stale-data 选项可以配置，在从节点完成同步之前是否正常接收客户端请求 为yes 表示正常接收 no 如果没有同步完数据 有客户端请求时返回错误（具体参见redis.conf 中的说明）
复制方式：
基于rdb文件的复制
无硬盘复制
增量复制

2、哨兵机制 sentinel
哨兵可以检测master 和slave 的状态
当master挂掉以后选举出新的master （哨兵也可以做集群，增加可用性）
哨兵监控redis状态的同时也会监控其他哨兵的状态。

配置哨兵：
1）复制sentinel.conf 配置文件到bin目录
2）修改配置
sentinel monitor mymaster 192.168.159.10 6379 2 配置要监控的master节点 ip 端口 第三个参数2 表示有几个哨兵投票才起作用 我们三个哨兵配置为2
sentinel down-after-milliseconds mymaster 10000 配置在多少毫秒之内 主节点没有响应就判断为离线
然后开始从 slave中选举出新的master
3)启动哨兵
运行 ./redis-sentinel ./sentinel.conf

[root@192 bin]# ./redis-sentinel ./sentinel.conf
8577:X 05 Feb 22:56:04.349 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.0.7 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 8577
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

8577:X 05 Feb 22:56:04.351 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
8577:X 05 Feb 22:56:04.351 # Sentinel runid is e01630b36aa383688bf8609a9622045d2620d017
8577:X 05 Feb 22:56:04.351 # +monitor master mymaster 192.168.159.10 6379 quorum 2
8577:X 05 Feb 22:56:04.404 * +slave slave 192.168.159.12:6379 192.168.159.12 6379 @ mymaster 192.168.159.10 6379
8577:X 05 Feb 22:56:04.461 * +slave slave 192.168.159.11:6379 192.168.159.11 6379 @ mymaster 192.168.159.10 6379

4)哨兵集群
直接在多台服务器启动哨兵即可 这里 三台服务器都按照上述步骤修改配置并启动哨兵。
多台哨兵启动时可以看到哨兵同事监控了哨兵的状态 如下：

[root@192 bin]# ./redis-sentinel ./sentinel.conf
7971:X 05 Feb 23:02:31.869 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.0.7 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 7971
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

7971:X 05 Feb 23:02:31.872 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
7971:X 05 Feb 23:02:31.873 # Sentinel runid is e83812b0bad75bb5e50886b76363668a4fc0d1b7
7971:X 05 Feb 23:02:31.873 # +monitor master mymaster 192.168.159.10 6379 quorum 2
7971:X 05 Feb 23:02:33.608 * +sentinel sentinel 192.168.159.11:26379 192.168.159.11 26379 @ mymaster 192.168.159.10 6379
7971:X 05 Feb 23:02:33.811 * +sentinel sentinel 192.168.159.12:26379 192.168.159.12 26379 @ mymaster 192.168.159.10 6379

哨兵选举演示。
通过客户端关闭master redis 可以看到哨兵重新选举了新的 master 节点 为 192.168.159.12 如下：

8507:X 05 Feb 23:09:39.961 # +sdown master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.028 # +odown master mymaster 192.168.159.10 6379 #quorum 2/2
8507:X 05 Feb 23:09:40.028 # +new-epoch 1
8507:X 05 Feb 23:09:40.028 # +try-failover master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.098 # +vote-for-leader 0ffa476301677a36b9e83e4a3305df9837cb06ee 1
8507:X 05 Feb 23:09:40.109 # 192.168.159.10:26379 voted for e83812b0bad75bb5e50886b76363668a4fc0d1b7 1
8507:X 05 Feb 23:09:40.124 # 192.168.159.11:26379 voted for 0ffa476301677a36b9e83e4a3305df9837cb06ee 1
8507:X 05 Feb 23:09:40.165 # +elected-leader master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.165 # +failover-state-select-slave master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.272 # +selected-slave slave 192.168.159.12:6379 192.168.159.12 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.273 * +failover-state-send-slaveof-noone slave 192.168.159.12:6379 192.168.159.12 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:40.361 * +failover-state-wait-promotion slave 192.168.159.12:6379 192.168.159.12 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:41.121 # +promoted-slave slave 192.168.159.12:6379 192.168.159.12 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:41.121 # +failover-state-reconf-slaves master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:41.201 * +slave-reconf-sent slave 192.168.159.11:6379 192.168.159.11 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:42.157 * +slave-reconf-inprog slave 192.168.159.11:6379 192.168.159.11 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:42.343 # -odown master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:43.205 * +slave-reconf-done slave 192.168.159.11:6379 192.168.159.11 6379 @ mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:43.310 # +failover-end master mymaster 192.168.159.10 6379
8507:X 05 Feb 23:09:43.310 # +switch-master mymaster 192.168.159.10 6379 192.168.159.12 6379
8507:X 05 Feb 23:09:43.316 * +slave slave 192.168.159.11:6379 192.168.159.11 6379 @ mymaster 192.168.159.12 6379
8507:X 05 Feb 23:09:43.317 * +slave slave 192.168.159.10:6379 192.168.159.10 6379 @ mymaster 192.168.159.12 6379
8507:X 05 Feb 23:09:53.336 # +sdown slave 192.168.159.10:6379 192.168.159.10 6379 @ mymaster 192.168.159.12 6379

在 192.168.159.12 redis中 执行命令 set name zhang 其他节点 执行 get name 可以获取到 zhang 如下：

127.0.0.1:6379> get name
"zhang"
127.0.0.1:6379> 

再次启动 192.168.159.10（原来的master节点）发现节点状态变为了 slave 如下

8507:X 05 Feb 23:18:11.923 # -sdown slave 192.168.159.10:6379 192.168.159.10 6379 @ mymaster 192.168.159.12 6379

[root@192 bin]# ./redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.159.12
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:136084
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379> 

哨兵+复制 才能组成redis 高可用

3、集群（3.0以后的功能）

之前redis 中所有的数据都保存在一个节点中，数据量大时会有性能问题。redis集群会把数据分片保存到多个节点，多个master共同保存一份数据，每个master又都有自己的slave 和哨兵，如下图

3.0之前实现方式：客户端 根据key 的hash值对服务节点数量取模,进行数据分片
3.0之后 redis提供了分片的机制 客户端不用做处理
slot(槽) 的概念 在redis集群中一共会有16384个槽
根据key 的 crc16算法 ，得到的结果再对16384进行取模。假如有有三个节点 16384/3=5460
node 1 保存槽位 0-5460
node2 保存槽位5461-10922
node3 保存槽位10923-15383
如果增加了节点 就会出现数据迁移 1-3个节点上都有一部分数据要迁移到新节点中。
需要人工迁移， 有一个脚本 redis-trib.rb
目前使用这种方案的比较少，因为3.0刚提供，3.0之前市面上提供了集群方案如下。
1）redis shardding jedis客户端支持shardding操作。 根据一致性hash取模 实现
2）codis （豌豆荚提供的分片策略 目前 应用比较广泛）基于redis2.8代码分支开发了一个codis-server。集成了分片操作。
3）twemproxy

不管用哪种方案，增删节点时都会涉及到 数据的迁移。目前应用广泛的解决方式就是 pre-shardding （预分片）
假如我只需要三台redis服务，那么我部署9台。每台服务器上部署三台（共九个redis节点），这样不用增加硬件，前期redis数据量不大时还可以提高cpu利用率。日后如果数据量变大，只需要将每台机器上的三台redis服务迁移到新的服务器上就可以了。不用进行任何数据分片处理