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>

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zgffgf.html