java架构之路-（Redis专题）Redis的主从、哨兵和集群

　　咱们使用的redis，单机的绝对作不到高可用的，万一单机的redis宕机了，就没有备用的了，咱们能够采用集群的方式来保证咱们的高可用操做。

主从架构

　　

　　大体就是这样的，一个主节点，两个从节点（通常两个就能够了）

主从工做原理

 　　若是你为master配置了一个slave，无论这个slave是不是第一次链接上Master，它都会发送一个SYNC命 令(redis2.8版本以前的命令)给master请求复制数据。 master收到SYNC命令后，会在后台进行数据持久化经过bgsave生成最新的rdb快照文件，持久化期间， master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以 后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，而后再加载到内存中。而后master再将以前缓存在内存中的命令发送给slave。 当master与slave之间的链接因为某些缘由而断开时，slave可以自动重连Master，若是master收到了多 个slave并发链接请求，它只会进行一次持久化，而不是一个链接一次，而后再把这一份持久化的数据发送 给多个并发链接的slave。 当master和slave断开重连后，通常都会对整份数据进行复制。但从redis2.8版本开始，master和slave断开重连后支持部分复制。

　　咱们在上述文字中能够得出，咱们的master获得了SYNC命令之后，仍是会继续接收咱们客户端的命令的，或者说，咱们的slave第一次全量复制了，而第二次就再也不须要全量复制了，那么就提到了咱们的数据部分复制

数据部分复制

　　从2.8版本开始，slave与master可以在网络链接断开重连后只进行部分数据复制。 master会在其内存中建立一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它全部的 slave都维护了复制的数据下标offset和master的进程id，所以，当网络链接断开后，slave会请求master 继续进行未完成的复制，从所记录的数据下标开始。若是master进程id变化了，或者从节点数据下标 offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

　　那么咱们实际搭建一下咱们的redis主从架构。

1.首先咱们准备三台已经安装好redis的服务器，不会安装的小伙伴能够回到我之后的博客去看一下，超详细http://www.javashuo.com/article/p-quotyjwx-gk.html

2.修改咱们的主节点和从节点配置，将protected-mode no修改成yes，大概在88行，将咱们bind 127.0.0.1修改成bind 0.0.0.0，启动一下咱们的主节点，而后分别测试一下从节点的服务器是否能够链接咱们的主节点（我怕大家防火墙开着），输入$ redis-cli -h  主节点IP   -p  主节点redis端口 。

[root@iZm5ec3zn3tzdvp7ttnnosZ redis-5.0.5]# ./src/redis-cli -h 47.104.129.103 -p 6379
47.104.129.103:6379> 

注意：咱们须要保证主节点和从节点是能够互通的

3.确保能够链接了，咱们来配置从节点，咱们全局搜索一下replica-read-only 改成replica-read-only yes（搜不到本身写上replica-read-only yes）大概在326行，表示从节点只读不写。在replica‐read‐only yes上面设置replicaof 47.104.129.103 6379。

# administrative / dangerous commands.
replicaof 47.104.129.103 6379
replica-read-only yes
# Replication SYNC strategy: disk or socket.

4.启动从节点，在主节点写入，查看从节点是否获得数据。

 配置完成，over~！

哨兵架构

　　其实咱们的主从架构只保证了数据的一致性，可是仍是解决不了咱们的高可用，咱们的master节点宕机了，咱们的服务仍是不可用的。没有Zookeeper的选举机制，咱们来看看咱们的哨兵架构。

哨兵就是保证咱们的master不会宕机，当master宕机之后，他会主动选举出来一个节点做为咱们的master。

　　sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都经过 sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，而且将新的redis 主节点通知给client端(这里面redis的client端通常都实现了订阅功能，订阅sentinel发布的节点变更消息)

　　配置起来也是很简单的，仍是咱们上一次的主从架构，而后加上咱们的哨兵集群。

1.准备好咱们刚才搭建完成的主从架构

2.准备三个以上的服务器（推荐奇数个服务器，有内部选举），安装咱们的Redis，须要服务器之间都相通，上面主从说过

3.修改咱们的sentinel.conf文件

daemonize yes #容许后台启动
sentinel monitor mymaster 192.168.0.60 6379 2 # 设置链接咱们的redis主从master 2表示服务器的数目/2取整数+1

4.输入src/redis‐sentinel sentinel.conf启动咱们的程序，这时咱们的端口是26379。注意：这里的启动再也不是src/redis‐server。

5.输入src/redis‐cli进入客户端，输入info，便可查看咱们的sentinel 信息。

　　哨兵模式也就很简单的配置好了，是在主从的基础之上搭建的，咱们以前的主从架构，当咱们的master宕机之后，redis也就算是宕机了，不会有任何选举机制，可是咱们的哨兵会有一个选举机制，当咱们的master宕机之后，咱们的哨兵集群会主动选举一个master，而后告知咱们的客户端，哪一个是新的master。即便咱们的曾经的master从新启动了，那也恢复不到主节点了，只能当作从节点（redis集群会详细说这个选举）

Redis集群架构

 　　咱们的哨兵架构，几乎能够作到了咱们的要实现的高可用，可是哨兵的选举仍是须要时间的，并且中间会阻塞客户端的请求，假如咱们的选举消耗了1秒（实际可能几秒，高则几十秒），就在这1秒的时候来了客户端的请求，那个请求也是不可用的，而且咱们的读写的节点实际仍是单节点的，这时咱们有了更好的方案，咱们的Redis集群架构，而且如今Redis的集群架构作的也很成熟了。

 　　也就是咱们Redis的集群其实就是一个个小的主从结合在一块儿（官方建议小于1000个小主从），变成了咱们的Redis集群，每一个小主从也就是咱们的Redis数据分片，每一个小主从的数据存储是不同的，内部是有一套他本身的运算规则的。咱们仍是先来看一下如何配置，上文提过的简单的我就直接过了啊。

　　1.准备9台服务器，保证互通，下载解压。

　　2.编辑咱们的redis.conf文件

　　　　(1)daemonize yes # 设置后台启动，大概在136行

　　　　(2)cluster-enabled yes # 是否开启集群模式，大概在832行

　　　　(3)cluster-config-file nodes‐8001.conf #集群节点信息文件，这里800x最好和port对应上，方便后期查找。大概在840行

　　　　(4)cluster-node-timeout 5000 # 节点离线超时时间，5000毫秒，大概在846行

　　　　(5)bind 0.0.0.0 #去掉bind绑定访问ip信息，大概在69行

　　　　(6)protected-mode no #关闭保护模式，大概在88行

　　　　(7)appendonly yes # 打开AOF，大概在699行

　　　　(8)requirepass xiaocai #设置redis访问密码，大概在507行

　　　　(9)masterauth xiaocai # 设置集群节点间访问密码，跟上面一致，大概在293行

　　3. 配置完成所有启动./src/redis-server redis.conf 检查是否启动成ps -ef|grep redis。咱们会看到这样的信息

 这里显示cluster，说到这咱们只差最后一步了。

　　4.咱们在任意服务器输入./src/redis-cli -a xiaocai --cluster create --cluster-replicas 2 172.31.179.185:6379 172.31.179.178:6379 172.31.179.184:6379 172.31.179.183:6379 172.31.179.180:6379 172.31.179.181:6379 172.31.179.182:6379 172.31.179.179:6379 172.31.179.177:6379命令，意思是要组建咱们的集群环境了，-a后面是密码xiaocai，--cluster-replicas 2这个数字2表示咱们每一个主节点有几个从节点，通常来讲前三个IP会设置为master，输入以后会有确认信息。咱们会看到这样的信息，咱们输入yes继续

 　　静静等待一会（时间也不会过久，时间过久的，你去检查一下网络之间互通吗），当咱们出现【ok】的画面也就是成功了。

  　　5.咱们随便找一个客户端输入./src/redis-cli -a xiaocai，进入咱们的客户端，输入cluster info，就能够查看到节点信息

 咱们看到cluster_known_nodes：9就是咱们一共拥有多少节点，cluster_size：3就是咱们拥有多少组主从架构。配置完成~！

扩展：输入cluster nodes还能够查看咱们的节点关联信息。

　　咱们在刚才输入咱们的cluster info时，咱们看到了一个16384，其实就是一个Redis集群的片区，咱们在单节点来执行set命令时，并不必定会成功，你能够尝试不一样的key试一下，这就是咱们的Redis分片区的存储，当你的key属于那个片区下，就会存储到哪一个小主从内，其他的并不须要重复存储。在输入cluster nodes时会返回咱们的片区信息。片区是从0开始计算，最大到16383的。

　　今天就说到这里吧，下次咱们说下java代码来操做咱们的Redis。

 

最进弄了一个公众号，小菜技术，欢迎你们的加入