Redis：常用集群模式及其实现原理

参考：
浅谈Redis的主从复制
 Redis哨兵模式选举机制

Redis：常用集群模式及其实现原理

前言
一、主从复制
二、哨兵模式
三、Redis Cluster
四、其他集群
五、集群选择

前言

在服务开发中，单机都会存在单点故障的问题，即服务部署在一场台服务器上，一旦服务器宕机服务就不可用，所以为了让服务高可用，分布式服务就出现了，将同一服务部署到多台机器上，即使其中几台服务器宕机，只要有一台服务器可用服务就可用。

Redis也是一样，为了解决单机故障引入了主从复制，但主从模式存在一个问题：master节点故障后服务，需要人为的手动将slave节点切换成为maser节点后服务才恢复。Redis为解决这一问题又引入了哨兵模式，哨兵模式能在master节点故障后能自动将salve节点提升成master节点，不需要人工干预操作就能恢复服务可用。

但是主从模式、哨兵模式都没有达到真正的数据sharding（分片）存储，每个Redis实例中存储的都是全量数据，所以Redis Cluster就诞生了，实现了真正的数据分片存储。但是由于Redis Cluster发布得比较晚(2015年才发布正式版 )，各大厂等不及了，陆陆续续开发了自己的Redis数据分片集群模式，比如：Twemproxy、Codis等。

一、主从复制

Redis单节点虽然有通过RDB和AOF持久化机制能将数据持久化到硬盘上，但数据是存储在一台服务器上的，如果服务器出现硬盘故障等问题，会导致数据不可用，而且读写无法分离，读写都在同一台服务器上，请求量大时会出现I/O瓶颈。

为了避免单点故障和读写不分离，Redis 提供了复制（replication）功能实现master数据库中的数据更新后，会自动将更新的数据同步到其他slave数据库上。

在这里插入图片描述

如上Redis主从结构特点：一个master可以有多个salve节点；salve节点可以有slave节点，从节点是级联结构。复制类型可以根据是否是全量而分为全量同步和增量同步。

当主数据库崩溃时，需要手动切换从数据库成为主数据库:

在从数据库中使用SLAVEOF NO ONE命令将slave提升为master继续服务
启动之前崩溃的master，然后使用SLAVEOF命令将其设置成新master的slave，即可同步数据

1. 主从复制原理

主从复制可以根据数据同步量分为全量同步和增量同步两种方式。

在这里插入图片描述

全量同步

Redis全量复制一般发生在slave的初始阶段，这时slave需要将master上的数据都复制一份，具体步骤如下：

slave连接master，发送SYNC命令；
master接到SYNC命令后，执行BGSAVE命令生产RDB文件并使用缓冲区记录此后执行的所有写命令；
master的BGSAVE执行完成后，向所有的slave发送快照文件，并在发送过程中继续记录执行的写命令；
slave收到快照后，丢弃所有的旧数据，载入收到的数据；
master快照发送完成后就会开始向slave发送缓冲区的写命令；
slave完成对快照的载入，并开始接受命令请求，执行来自master缓冲区的写命令；
slave完成上面的数据初始化后就可以开始接受用户的读请求了。

增量复制

增量复制实际上就是在slave初始化完成后开始正常工作时master发生写操作同步到slave的过程。增量复制的过程主要是master每执行一个写命令就会向slave发送相同的写命令，slave接受并执行写命令，从而保持主从一致。

2. 主从同步策略

主从同步刚连接的时候进行全量同步；全量同步结束后开始增量同步。如果有需要，slave在任何时候都可以发起全量同步，其主要策略就是无论如何首先会尝试进行增量同步，如果不成功，则会要求slave进行全量同步，之后再进行增量同步。

注意：如果多个slave同时断线需要重启的时候，因为只要slave启动，就会和master建立连接发送SYNC请求和主机全量同步，如果多个同时发送SYNC请求，可能导致master IO突增而发送宕机。

3. 主从模式特点与优缺点

特点：

采用异步复制；
可以一主多从；
主从复制对于master来说是非阻塞的，也就是说slave在进行主从复制的过程中，master依然可以处理请求；
主从复制对于slave来说也是非阻塞的，也就是说slave在进行主从复制的过程中也可以接受外界的查询请求，只不过这时候返回的数据不一定是正确的。为了避免这种情况发生，可以在slave的配置文件中配置，在同步过程中阻止查询；
每个slave可以接受来自其他slave的连接；
主从复制提高了Redis服务的扩展性，避免单节点问题，另外也为数据备份冗余提供了一种解决方案；
为了降低主redis服务器写磁盘压力带来的开销，可以配置让主redis不在将数据持久化到磁盘，而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘，不过这样会存在一个问题，就是主redis服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空

优缺点：

优点: 主从结构具有读写分离，提高效率、数据备份，提供多个副本等优点
缺点: 不具备自动容错和恢复功能，主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预

二、哨兵模式

第一种主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用，这时候就需要哨兵模式登场了（Redis2.6版本开始提供，直到2.8版本逐渐稳定）

哨兵模式核心还是主从复制，只不过在相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。

在这里插入图片描述
如上图，哨兵本身也有单点故障的问题，所以在一个一主多从的Redis系统中，可以使用多个哨兵进行监控，哨兵不仅会监控主数据库和从数据库，哨兵之间也会相互监控。每一个哨兵都是一个独立的进程，作为进程它会独立运行。

在这里插入图片描述

1. 哨兵模式作用

监控所有服务器是否正常运行：通过发送命令返回监控服务器的运行状态，除监控主服务器、从服务器外，哨兵之间也相互监控。

故障切换：当哨兵监测到master宕机，会自动选举slave切换成新的master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

2. 哨兵实现原理

哨兵在启动进程时，会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：

sentinel monitor master-name ip port quorum
# master-name是主数据库的名字
# ip和port 是当前主数据库地址和端口号
# quorum表示在执行故障切换操作前，需要多少哨兵节点同意。

这里之所以只需要连接主节点，是因为通过主节点的info命令，获取从节点信息，从而和从节点也建立连接，同时也能通过主节点的info信息知道新增从节点的信息。
一个哨兵节点可以监控多个主节点，但是并不提倡这么做，因为当哨兵节点崩溃时，同时有多个集群切换会发生故障。哨兵启动后，会与主数据库建立两条连接。

订阅主数据库_sentinel_:hello频道以获取同样监控该数据库的哨兵节点信息
定期向主数据库发送info命令，获取主数据库本身的信息。

跟主数据库建立连接后会定时执行以下三个操作：

每隔10s向master和slave发送info命令。作用是获取当前数据库信息，比如发现新增从节点时，会建立连接，并加入到监控列表中，当主从数据库的角色发生变化进行信息更新。
每隔2s向主数据里和从数据库的_sentinel_:hello频道发送自己的信息。作用是将自己的监控数据和哨兵分享。每个哨兵会订阅数据库的_sentinel:hello频道，当其他哨兵收到消息后，会判断该哨兵是不是新的哨兵，如果是则将其加入哨兵列表，并建立连接。
每隔1s向所有主从节点和所有哨兵节点发送ping命令，作用是监控节点是否存活。

3. 主观下线和客观下线

哨兵节点发送ping命令时，当超过一定时间(down-after-millisecond)后，如果节点未回复，则哨兵认为主观下线。如果该节点为主数据库，哨兵会进一步判断是够需要对其进行故障切换，这时候就要发送命令(SENTINEL is-master-down-by-addr)询问其他哨兵节点是否认为该主节点是主观下线，当达到指定数量(quorum)时，哨兵就会认为是客观下线。
当主节点客观下线时就需要进行主从切换，主从切换的步骤为：

选出领头哨兵；
领头哨兵所有的slave选出优先级最高的从数据库。优先级可以通过slave-priority选项设置；
如果优先级相同，则从复制的命令偏移量越大（即复制同步数据越多，数据越新），越优先；
如果以上条件都一样，则选择run ID较小的从数据库（Redis每次启动时都会生成随机的run ID作为Redis的标识）。

选出一个从数据库后，哨兵发送slaveof no one命令升级为主数据库，并发送slaveof [ip] [port]命令将其他从节点的主数据库设置为新的主数据库。

选点的依据依次是：
网络连接正常 -> 5 秒内回复过 INFO 命令 -> 10*down-after-milliseconds 内与主连接过的 -> slave-priority优先级 -> 复制偏移量 -> 运行id较小的

4. 哨兵模式优缺点

优点

哨兵模式是基于主从模式的，解决可主从模式中master故障不可以自动切换故障的问题。

不足

哨兵模式始终只有一个Redis主机来接收和处理写请求，写操作还是受单机瓶颈影响，没有实现真正的分布式架构
集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
哨兵模式是中心化的集群实现方案，每个从机和主机的耦合度很高，master宕机到salve选举master恢复期间服务不可用

主从模式或哨兵模式每个节点存储的数据都是全量的数据，数据量过大时，就需要对存储的数据进行分片后存储到多个redis实例上。此时就要用到Redis Sharding技术。

三、Redis Cluster

Redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。cluster模式为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现)，采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式，完全去中心化。

在这里插入图片描述
如上图，官方推荐，集群部署至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式。

1. Redis Cluster特点

Redis Cluster有以下几个重要的特征：

集群完全去中心化，采用多主多从；所有的Redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。每一个分区都是由一个Redis主机和多个从机组成，分片和分片之间是相互平行的。
Redis Cluster的分片特征在于将空间拆分为16384个槽位，某一个节点负责其中一些槽位。每一个master节点负责维护一部分槽，以及槽所映射的键值数据；集群中每个节点都有全量的槽信息，通过槽每个node都知道具体数据存储到哪个node上。
Redis Cluster提供一定程度的可用性，可以在某个节点宕机或者不可达的情况继续处理命令；
Redis Cluster不存在中心节点或代理节点，集群的其中一个最重要的设计目标是达到线性可扩展性，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

Redis Cluster采用虚拟哈希槽分区而非一致性hash算法，预先分配一些卡槽，所有的键根据哈希函数映射到这些槽内，每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。

2. Redis Cluster原理

Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个master节点都会负责一部分的槽，当有某个key被映射到某个master负责的槽，那么这个master负责为这个key提供服务，至于哪个master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成（redis-trib.rb脚本）。这里值得一提的是，在Redis Cluster中，只有master才拥有槽的所有权，如果是某个master的slave，这个slave只负责槽的使用，但是没有所有权。

如下所示：
在这里插入图片描述

那么Redis Cluster是怎么存储的呢？

首先，在Redis的每一个节点上，都有这么两个东西：一个是插槽（slot） 可以理解为是一个可以存储两个数值的变量，其取值范围是：0～16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取key时，Redis会根据crc16的算法得出一个结果，然后把结果对 16384求余，这样每个 key 都会对应一个编号在 0～16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

理论上就给集群中的每个节点至少一个备用的Redis服务，这个备用的Redis称为从节点（slave）。然后，每一个节点都存有这个集群所有主节点以及从节点的信息，它们之间通过互相的ping-pong判断是否节点可以连接上。

如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入faill状态。这就是我们的Redis的投票机制。

3. Redis Cluster请求路由方式

客户端直连 Redis 服务，进行读写操作时，Key 对应的 Slot 可能并不在当前直连的节点上，经过“重定向”才能转发到正确的节点。

在这里插入图片描述

和普通的查询路由相比，Redis Cluster 借助客户端实现的请求路由是一种混合形式的查询路由，它并非从一个 Redis 节点到另外一个 Redis，而是借助客户端转发到正确的节点。实际应用中，可以在客户端缓存 Slot 与 Redis 节点的映射关系，当接收到 MOVED 响应时修改缓存中的映射关系。如此，基于保存的映射关系，请求时会直接发送到正确的节点上，从而减少一次交互，提升效率。

Ref：Redis——cluster集群原理

四、其他集群

Redis在3.0版本前只支持单实例模式，虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业等不急了，在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

1. 客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。这种方案的模式如图所示。
在这里插入图片描述

客户端分片的优缺点：
优点：客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

一致性哈希算法:
是分布式系统中常用的算法。比如，一个分布式的存储系统，要将数据存储到具体的节点上，如果采用普通的hash方法，将数据映射到具体的节点上，如mod(key,d)，key是数据的key，d是机器节点数，如果有一个机器加入或退出这个集群，则所有的数据映射都无效了。
一致性哈希算法解决了普通余数Hash算法伸缩性差的问题，可以保证在上线、下线服务器的情况下尽量有多的请求命中原来路由到的服务器。
实现方式：一致性hash算法，比如MURMUR_HASH散列算法、ketamahash算法
比如Jedis的Redis Sharding实现，采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。
采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

不足：
这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。

运维成本比较高，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。

在不同的客户端程序中，维护相同的路由分片逻辑成本巨大。比如：Java项目、PHP项目里共用一套Redis集群，路由分片逻辑分别需要写两套一样的逻辑，以后维护也是两套。

客户端分片有一个最大的问题就是，服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。如果能把客户端分片模块单独拎出来，形成一个单独的模块(中间件)，作为客户端和服务端连接的桥梁就能解决这个问题了，此时代理分片就出现了。

2. 代理分片

Redis代理分片用得最多的就是Twemproxy，由Twitter开源的Redis代理，其基本原理是：通过中间件的形式，Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

在这里插入图片描述
Twemproxy的优点：
客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑。
支持无效Redis实例的自动删除。
Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

Twemproxy的不足：
由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。
没有友好的监控管理后台界面，不利于运维监控。
Twemproxy最大的痛点在于，无法平滑地扩容/缩容。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。
Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。

3. Codis

Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在GitHub上开源。

在这里插入图片描述

在Codis的架构图中，Codis引入了Redis Server Group，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。当一个主CodisRedis挂掉时，Codis不会自动把一个从CodisRedis提升为主CodisRedis，这涉及数据的一致性问题（Redis本身的数据同步是采用主从异步复制，当数据在主CodisRedis写入成功时，从CodisRedis是否已读入这个数据是没法保证的），需要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。

如果手动处理觉得麻烦，豌豆荚也提供了一个工具Codis-ha，这个工具会在检测到主CodisRedis挂掉的时候将其下线并提升一个从CodisRedis为主CodisRedis。

Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有固定的编号，范围是1~1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。
例如，如果某个Key通过算法“crc32(key)%1024”得到的数字是5，就放到编码为5的slot（箱子）。1个slot只能放1个Redis Server Group，不能把1个slot放到多个Redis Server Group中。1个Redis Server Group最少可以存放1个slot，最大可以存放1024个slot。因此，Codis中最多可以指定1024个Redis Server Group。

Codis最大的优势在于支持平滑增加（减少）Redis Server Group（Redis实例），能安全、透明地迁移数据，这也是Codis 有别于Twemproxy等静态分布式 Redis 解决方案的地方。Codis增加了Redis Server Group后，就牵涉到slot的迁移问题。
例如，系统有两个Redis Server Group，Redis Server Group和slot的对应关系如下。

当增加了一个Redis Server Group，slot就要重新分配了。Codis分配slot有两种方法：
第一种：通过Codis管理工具Codisconfig手动重新分配，指定每个Redis Server Group所对应的slot的范围，例如：可以指定Redis Server Group和slot的新的对应关系如下：

第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。

五、集群选择

Redis Cluster主要是针对海量数据+高并发+高可用的场景。如果你的数据量很大，那么建议用Redis Cluster，数据量不是很大时，使用sentinel就够了。Redis Cluster的性能和高可用性均优于哨兵模式。