redis集群5种模式

主从模式

主从模式是三种模式中最简单的，在主从复制中，数据库分为2类：主数据库和从数据库

* 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库

* 从数据库一般都是只读的，并且接收主数据库同步过来的数据

* 一个master可以拥有多个slave，但是一个slave只能对应一个master

* slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来

* master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务

* master挂了以后，不会在slave节点中重新选一个master

工作机制：

当slave启动后，主动向master发送SYNC命令。master接受到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次收到的写命令都会同步发送给slave，保证主从数据一致性。

缺点：

从上面可以看出，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。

 

Sentinel（哨兵）模式

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因为哨兵应运而生。

哨兵的作用就是监控redis集群的运行状况。特点如下：

* sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义

* 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master

* 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据

* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群

* 多sentinel配置的时候，sentinel之间也会自动监控

* 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心

* 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis

* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了
工作机制：

* 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 

* 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。 

* 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态

* 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 

* 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 

* 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 

* 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；
  若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

注意点：
当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

 

Cluster模式

为什么会出现Cluster模式？哨兵模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实力中，cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinal和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要3个主数据库才能正常运行，新增节点非常方便。

cluster集群特点：

* 多个redis节点网络互联，数据共享

* 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用

* 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，
  并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为
  
* 支持在线增加、删除节点

* 客户端可以连接任何一个主节点进行读写

Codis与RedisCluster的原理详解

背景介绍#

我们先来看一下为什么要做集群，如果我们要部署一个单节点Redis，很明显会遇到单点故障的问题。

首先能想到解决单点故障的方法，就是做主从，但是当有海量存储需求时，单一的主从结构就会出问题，说问题之前要先了解一下主从之间是如何复制的。

我们把Redis分为三个部分，分别是客户端、主节点以及从节点，如果从节点要同步主节点的数据，它首先会发Sync指令给主节点，主节点收到指令之后会执行BGSAVE命令生成RDB文件，这个RDB文件指的是快照文件，它是Redis两种备份方式的其中一种，另一种叫AOF，它的原理是将所有的写入指令存入文件，mysql的binlog原理是一样的。

如果主节点在生成RDB的过程当中，客户端发来了写入指令，这个时候主节点会把指令全部写入缓冲区，等RDB生成完了，会把RDB文件发送给从节点，最后再把缓冲区的指令发送给从节点。这样就完成了整个的复制。

我们刚才说单纯地做主从是有缺陷的，这个缺陷就是如果我们要存储海量的数据，那么BGSAVE指令生成的RDB文件会非常巨大，这个文件传送给从节点也会非常慢，如果缓冲区命令很多的话，从节点同步数据时也会执行很久，所以，要解决单点问题和海量存储问题，还是要考虑做集群。

Redis常见集群方案#

Redis集群方案目前主流的有三种，分别是Twemproxy、Codis和Redis Cluster。

Twemproxy，是推特开源的，它最大的缺点就是无法平滑的扩缩容，而Codis解决了Twemproxy扩缩容的问题，而且兼容了Twemproxy，它是由豌豆荚开源的，和Twemproxy都是代理模式。其实Codis能发展起来的一个主要原因是它是在Redis官方集群方案漏洞百出的时候率先成熟稳定的。以现在的Redis官方集群方案，这两个好像没有太大差别了，不过我也没有去做性能测试，不清楚哪个最好。

Redis Cluster是由官方出品的，用去中心化的方式实现，不属于代理模式，今天主要讲codis，redis cluster后面也会过一下。下面，来看一下Codis的实现原理。

Codis原理#

我们换一种方式去讲，就按照Codis的架构演进一下，这样理解会比较清晰一点，假如现在只有一个Redis Server，怎么让它变得高可用？

开篇的时候也有讲，首先，能想到的就是做主从，这样就算主宕机了，从节点也能马上接替主节点的位置。

我们现在已经做成主从结构了，那到底是谁来负责主从之间的切换？

就是它，Sentinel，中文名叫哨兵，它呢，在Redis里面主要负责监控主从节点，如果主节点挂了，就会把从拉起来。但是哨兵本身也存在单点问题，所以它也需要做集群。

那么问题来了，哨兵是如何做主从切换呢？来看下哨兵的运行机制。

假如有三个哨兵和一主两从的节点，下面是一主多从，哨兵之间会互相监测运行状态，并且会交换一下节点监测的状态，同时哨兵也会监测主从节点的状态。

如果检测到某一个节点没有正常回复，并且距离上次正常回复的时间超过了某个阈值，那么就认为该节点为主观下线。

这个时候其他哨兵也会来监测该节点是不是真的主观下线，如果有足够多数量的哨兵都认为它确实主观下线了，那么它就会被标记为客观下线，这个时候哨兵会找下线节点的从节点，然后与其他哨兵协商出一个从节点做主节点，并将剩余的从节点指向新的主节点。

关于主从节点的切换有两个环节，第一个是哨兵要选举出领头人来负责下线机器的故障转移，第二是从Slave中选出主节点，领头人的选举规则是谁发现客观下线谁就可以马上要求其他哨兵认自己做老大，其他哨兵会无条件接受第一个发过来的人，并告知老大，如果超过一半人都同意了，那他老大的位置就坐实了。

关于从节点选举，一共有四个因素影响选举的结果，分别是断开连接时长、优先级排序、复制数量、进程id，如果连接断开的比较久，超过了某个阈值，就直接失去了选举权，如果拥有选举权，那就看谁的优先级高，这个在配置文件里可以设置，数值越小优先级越高，如果优先级相同，就看谁从master中复制的数据最多，选最多的那个，如果复制数量也相同，就选择进程id最小的那个。

现在继续回过来，刚才讲痛点的时候说了，如果有存储海量数据的需求，同步会非常缓慢，所以我们应该把一个主从结构变成多个，把存储的key分摊到各个主从结构中来分担压力。

就像这样，代理通过一种算法把要操作的key经过计算后分配到各个组中，这个过程叫做分片，我们来看一下分片的实现原理。

分片算法#

在Codis里面，它把所有的key分为1024个槽，每一个槽位都对应了一个分组，具体槽位的分配，可以进行自定义，现在如果有一个key进来，首先要根据CRC32算法，针对key算出32位的哈希值，然后除以1024取余，然后就能算出这个KEY属于哪个槽，然后根据槽与分组的映射关系，就能去对应的分组当中处理数据了。

CRC全称是循环冗余校验，主要在数据存储和通信领域保证数据正确性的校验手段，我去看了这个算法的原理，还没理解透彻，这里就先不讲了，省得误导大家。

我们继续回过来，刚才所讲的槽位和分组的映射关系就保存在codis proxy当中，但是codis proxy它本身也存在单点问题，所以需要对proxy做一个集群。

部署好集群之后，有一个问题，就是槽位的映射关系是保存在proxy里面的，不同proxy之间怎么同步映射关系？

在Codis中使用的是Zookeeper来保存映射关系，由proxy上来同步配置信息，其实它支持的不止zookeeper，还有etcd和本地文件。在zookeeper中保存的数据格式就是这个样子。除了这个还会存储一些其他的信息，比如分组信息、代理信息等，感兴趣可以自己去了解一下。

现在还有一个问题，就是codis proxy如果出现异常怎么处理，这个可能要利用一下k8s中pod的特性，在k8s里面可以设置pod冗余的数量，k8s会严格保证启动的数量与设置一致，所以只需要一个进程监测Proxy的异常，并且把它干掉就可以了，k8s会自动拉起来一个新的proxy。

codis给这个进程起名叫codis-ha，codis-ha实时监测proxy的运行状态，如果有异常就会干掉，它包含了哨兵的功能，所以豌豆荚直接把哨兵去掉了。

但是codis-ha在Codis整个架构中是没有办法直接操作代理和服务，因为所有的代理和服务的操作都要经过dashboard处理。所以部署的时候会利用k8s的亲和性将codis-ha与dashboard部署在同一个节点上。

除了这些，codis自己开发了集群管理界面，集群管理可以通过界面化的方式更方便的管理集群，这个模块叫codis-fe，我们可以看一下这个界面。

最后就是redis客户端了，这个没什么好讲的，客户端是直接通过代理来访问后端服务的。

Redis Cluster原理#

下面来看一下redis cluster的原理，它和codis不太一样，Codis它是通过代理分片的，但是Redis Cluster是去中心化的没有代理，所以只能通过客户端分片，它分片的槽数跟Codis不太一样，Codis是1024个，而Redis cluster有16384个，槽跟节点的映射关系保存在每个节点上，每个节点每秒钟会ping十次其他几个最久没通信的节点，其他节点也是一样的原理互相PING ，PING的时候一个是判断其他节点有没有问题，另一个是顺便交换一下当前集群的节点信息、包括槽与节点映射的关系等。客户端操作key的时候先通过分片算法算出所属的槽，然后随机找一个服务端请求。

但是可能这个槽并不归随机找的这个节点管，节点如果发现不归自己管，就会返回一个MOVED ERROR通知，引导客户端去正确的节点访问，这个时候客户端就会去正确的节点操作数据。

这是RedisCluster大概的原理，下面看一下Codis跟RedisCluster简要的区别。

 

转自：https://www.cnblogs.com/pingyeaa/p/11294773.html