redis的主从复制到读写分离到哨兵模式

目录

 

一、什么是自从复制

1.1 主从复制的作用

二、读写分离

2.1 主从同步延迟

三、redis的哨兵机制 

四、redis的集群模式(cluster)

4.1 哨兵模式下存在的问题

4.2 集群模式的简介

4.3 集群模式的读写策略

4.4 集群模式的failover(故障切换)

---

一、什么是自从复制

主从复制，意思是将一台主服务器(称为master，主节点)的数据复制到其他的从服务器(称为slave，从节点)。这种数据的复制是单向的，只能从主节点往从节点复制。

一个主节点可以有多个从节点，但一个从节点就只能有一个主节点。

1.1 主从复制的作用

1. 数据的热备份：因为主机会往从机同步数据，所以万一主机的数据没了，也能从从机上恢复数据。

2. 主从切换技术：当主机出现问题时，可以由 从机 顶上继续提供服务。

3. 负载均衡：在主从复制的基础上，可以配合读写分离，即主机提供写服务，从机提供读服务，从而分担服务器的负载，尤其是在写少读多的情况下，通常用多个从节点来提供读服务，大大地提供并发量。

 

二、读写分离

因为用户的增多，数据的增多，单机的数据库往往支撑不住快速发展的业务，所以数据库集群就产生了！今天来说说读写分离的数据库集群方式！ 读写分离顾名思义就是读和写分离了，对应到数据库集群一般都是一主一从(一个主库，一个从库)或者一主多从(一个主库，多个从库)，业务服务器把需要写的操作都写到主数据库中，读的操作都去从库查询。主库会同步数据到从库保证数据的一致性。

这种方式可以把 访问(读)数据库 的压力从主机转移到从机上面。也就是在单机数据库无法支撑并发读写的时候，并且读的请求很多的情况下适合这种读写分离的数据库集群。但如果是写操作很多的情况，则不适合用这套方案，因为这套方案无法把写的压力从主机转移到从机。

但是 读写分离也有缺点： 

主从同步延迟；

2.1 主从同步延迟

如下图：

1）写请求A进行数据更新，但写库还没有来得及把更新的数据更新到读库

2）读请求B进行数据查询，请求B是访问的读库，获取的是旧值

3）因为写库和读库之间存在同步延迟，导致数据在不同库中不一致

 

三、redis的哨兵机制 

在主-从 模式里，如果主服务器宕机了，虽然可以由 从机 来代替主机继续服务，但这需要人工把 从机 切换成主机，需要人工干预，还会造成一段时间内服务不可用。

所以更多时候，我们推荐哨兵模式。

哨兵是一个独立的进程，其原理是：哨兵通过向redis服务器发送命令，等待redis服务器响应，从而监控多个运行中的redis实例。

如下图：

一个哨兵的结构：

哨兵的两个作用：

1. 通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。

2.当哨兵监测到master(主机)宕机，会自动将slave(从机)切换成主机，然后通过发布订阅模式通知其他从机，让从机修改配置文件，让它们切换主机。

但是单哨兵模式仍然是存在问题的。因为有可能因为网络原因，导致一个哨兵监听服务器的时候，误以为它挂了。

因此，存在 多哨兵模式 。

 

多哨兵的结构：

用多个哨兵进行监控，各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

多哨兵模式的故障切换failover(即主机宕机，切换从机)的过程是这样的：

假设主机宕机，哨兵1 先检测到这个结果，系统并不会立刻d进行failover过程，仅仅是哨兵1 主观的认为主服务器不可用，这个现象叫主观下线，仅仅代表哨兵1而已。

然后当其他哨兵也意识到主服务器不可用，并且这些哨兵达到一定数目后，哨兵之间就会进行投票，进行failover操作，切换成功后，就会通过发布订阅模式，通知各个哨兵把自己监控的从机 切换主机(切换成新的master主机)，这个过程叫客观下线。

（每个哨兵都会定时地向 其他哨兵、Master(主机)、Slave(从机) 发送消息，以确保对方还活着）

 

四、redis的集群模式(cluster)

4.1 哨兵模式下存在的问题

上面讲了redis的哨兵模式，但是哨兵模式还是有两个问题的：

1.  哨兵模式是不会对宕机了的从机进行failover(故障切换)的，原本连接这个从机的客户端也无法再获取新的可用从节点。

2. 哨兵模式下，所有redis的服务器都存储相同的数据，很浪费内存。

 

4.2 集群模式的简介

redis集群是一个由多个节点组成的分布式服务器集群。如下图所示，展示的是三主三从（根据官方推荐 集群部署至少要3台以上的 主节点。），每个主节点处理各自的数据，提供读写能力，从节点异步复制主节点的数据。

集群模式是数据分片的，分片即把数据分开放到不同的节点上。

 

4.3 集群模式的读写策略

redis集群模式下，每台redis主节点上存储了不同的内容。那数据是怎么分配存储和读取的呢？

其实客户端早就已经决定数据会被存储到哪个 redis 节点或者从哪个 redis 节点读取数据。cluster集群方案，采用的是虚拟槽分区，槽范围是0-16383，一共有16384个槽。槽是集群内数据管理和迁移的基本单位。比如上图的集群中有3个主节点，每个节点大致负责5500(约为16384/3)个槽的读写，节点会维护自身负责的虚拟槽。

cluster集群中的主节点负责处理槽（存储数据），从节点则是主节点的复制品；

当有数据需要存储的时候，我们根据以下公式计算存在哪个槽上。

slot = CRC16（key）& 16383

这种结构很容易添加或者删除节点。如果增加一个节点4，就需要从节点 1 ~ 3获得部分槽分配到节点 4 上。如果想移除节点 1，需要将节点 1 中的槽移到节点 2 ~ 3上，然后将没有任何槽的节点 1 从集群中移除即可。

 

4.4 集群模式的failover(故障切换)

在上文介绍哨兵模式的时候，哨兵可以做自动的故障转移。那cluster的故障转移是怎么做的呢？

在cluster中，A节点会发送PING消息给B节点，若是在规定时长内，没有收到回复，则A节点会判断B节点已下线，这时候A会向集群广播B节点已经下线的消息，如果集群中超过半数的节点都认为B节点已下线，B节点才会真正的被认为下线。

当有问题的节点下线后，若该节点是带有槽的主节点，那么就需要从它的从节点中选出一个替代它。当从节点发现它的主节点下线时，将会触发故障切换流程。