转载

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

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

主从架构

java架构之路-(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断开重连后支持部分复制。

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

我们在上述文字中可以得出,我们的master得到了SYNC命令以后,还是会继续接收我们客户端的命令的,或者说,我们的slave第一次全量复制了,而第二次就不再需要全量复制了,那么就提到了我们的数据部分复制

数据部分复制

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

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

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

1.首先我们准备三台已经安装好redis的服务器,不会安装的小伙伴可以回到我以后的博客去看一下,超详细 https://www.cnblogs.com/cxiaocai/p/11674716.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.启动从节点,在主节点写入,查看从节点是否得到数据。

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

配置完成,over~!

哨兵架构

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

哨兵就是保证我们的master不会宕机,当master宕机以后,他会主动选举出来一个节点作为我们的master。

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

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的集群架构做的也很成熟了。

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

也就是我们Redis的集群其实就是一个个小的主从结合在一起(官方建议小于1000个小主从),变成了我们的Redis集群,每个小主从也就是我们的Redis数据分片,每个小主从的数据存储是不一样的,内部是有一套他自己的运算规则的。我们还是先来看一下如何配置,上文提过的简单的我就直接过了啊。

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

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

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。我们会看到这样的信息 java架构之路-(Redis专题)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继续

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

静静等待一会(时间也不会太久,时间太久的,你去检查一下网络之间互通吗),当我们出现【ok】的画面也就是成功了。

java架构之路-(Redis专题)Redis的主从、哨兵和集群 5.我们随便找一个客户端输入./src/redis-cli -a xiaocai,进入我们的客户端,输入cluster info,就可以查看到节点信息

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

我们看到cluster_known_nodes:9就是我们一共拥有多少节点,cluster_size:3就是我们拥有多少组主从架构。配置完成~!

扩展:输入cluster nodes还可以查看我们的节点关联信息。

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

今天就说到这里吧,下次我们说下java代码来操作我们的Redis。

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

最进弄了一个公众号,小菜技术,欢迎大家的加入

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

原文  http://www.cnblogs.com/cxiaocai/p/11711377.html
正文到此结束
Loading...