目录

一、什么是自从复制

1.1 主从复制的作用

二、读写分离

2.1 主从同步延迟

三、redis的哨兵机制 

四、redis的集群模式(cluster)

4.1 哨兵模式下存在的问题

4.2 集群模式的简介

4.3 集群模式的读写策略

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

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

一个主节点可以有多个从节点&＃xff0c;但一个从节点就只能有一个主节点。

1.1 主从复制的作用

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

2. 主从切换技术&＃xff1a;当主机出现问题时&＃xff0c;可以由 从机 顶上继续提供服务。

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

二、读写分离

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

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

但是 读写分离也有缺点&＃xff1a; 

主从同步延迟&＃xff1b;

2.1 主从同步延迟

如下图&＃xff1a;

1&＃xff09;写请求A进行数据更新&＃xff0c;但写库还没有来得及把更新的数据更新到读库

2&＃xff09;读请求B进行数据查询&＃xff0c;请求B是访问的读库&＃xff0c;获取的是旧值

3&＃xff09;因为写库和读库之间存在同步延迟&＃xff0c;导致数据在不同库中不一致

三、redis的哨兵机制 

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

所以更多时候&＃xff0c;我们推荐哨兵模式。

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

如下图&＃xff1a;

一个哨兵的结构&＃xff1a;

哨兵的两个作用&＃xff1a;

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

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

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

因此&＃xff0c;存在 多哨兵模式 。

多哨兵的结构&＃xff1a;

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

多哨兵模式的故障切换failover(即主机宕机&＃xff0c;切换从机)的过程是这样的&＃xff1a;

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

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

&＃xff08;每个哨兵都会定时地向 其他哨兵、Master(主机)、Slave(从机) 发送消息&＃xff0c;以确保对方还活着&＃xff09;

四、redis的集群模式(cluster)

4.1 哨兵模式下存在的问题

上面讲了redis的哨兵模式&＃xff0c;但是哨兵模式还是有两个问题的&＃xff1a;

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

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

 

4.2 集群模式的简介

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

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

 

4.3 集群模式的读写策略

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

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

cluster集群中的主节点负责处理槽&＃xff08;存储数据&＃xff09;&＃xff0c;从节点则是主节点的复制品&＃xff1b;

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

slot &＃61; CRC16&＃xff08;key&＃xff09;& 16383

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

 

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

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

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

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