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主从架构。
# 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。
最进弄了一个公众号