Redis分布式篇

怼烎@ 2022-09-03 04:15 111阅读 0赞

# 为什么需要Redis集群 #

## 性能 ##

redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能会受到影响。这个时候我们希望有更多的redis服务来完成工作。

## 扩展 ##

第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法。

## 可用性 ##

第三个是可用性和安全的考虑。如果有一个Redis服务，一旦服务宕机，那么所有客户端都无法访问，会对业务造成很大的影响。另一个，如果硬件发生故障，而单机的数据无法恢复的话，带来的影响也是灾难性的。  
可用性、数据安全、性能都可以通过搭建多个Redis服务实现。其中有一个是主节点（master）,可以有多个从节点（slave）。主从之间通过数据同步，存储完全相同的数据。如果主节点发生故障，则从某个从节点改成主节点，访问新的主节点。

# Redis主从复制（replication） #

## 主从复制配置 ##

例如一主多从，203是主节点，在每个slave节点的redis.conf配置文件增加一行。

slaveof 192.168.8.203 6379

在主从切换的时候，这个配置会被重写成：

Generated by CONFIG REWRITE
    replicaof 192.168.8.203 6379

或者在启动服务时通过参数指定master节点：

./redis-server --slaveof 192.168.8.203 6379

或在客户端直接执行slaveof xx xx，使该redis实例成为主节点。  
启动后，查看群群状态：

redis> info replication

从节点不能写入数据（只读），只能从master节点同步数据。get成功。set失败

# 主从复制原理 #

## 连接阶段 ##

1，slave node启动时（执行slaveof命令），会在自己本地master node的信息，包括master node的host和ip。  
2，slave node内部有个定时任务replicationCron（源码replication.c），每隔1秒钟检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接，如果连接成功，从节点为该socket建议一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收RDB文件、接收命令传播等。  
当从节点变成了主节点的一个客户端之后，会给主节点发送ping请求。

## 数据同步阶段 ##

master node第一次执行全量复制，通过bgsave命令在本地生成一份RDB快照，将RDB快照文件发给slave node（如果超时会重连，可以调大repl-timeout的值）。slave node首先清除自己的旧数据，然后用RDB文件加载数据。

疑问：生成RDB期间，master接收到的命令怎么处理？  
开始生成RDB文件时，master会把所有新的写命令缓存内存中，在slave node保存了RDB之后，再将新的写命令复制给slave node。

## 命令传播阶段 ##

master node持续将写命令，异步复制给slave node  
延迟是不可避免的，只能通过网络优化。

repl-disable-tcp-nodelay no

当设置为yes时，tcp会对包进行合并从而减少带宽，但是发送的频率会降低，从节点数据延迟增加，一致性变差；具体发送频率与linux内核的配置有关，默认配置为40ms。当设置no时，tcp会立马将主节点的数据发送给从节点，带宽增加但延迟变小。

疑问：如果从节点有一段时间断开了与主节点的连接是不是要重新全量复制一遍？ 如果可以增量复制，怎么知道上次复制到哪里？

# 主从复制的不足 #

主从模式解决了数据备份和性能（通过读写分离）的问题，但是还是存在一些不足：  
1，RDB文件过大的情况下，同步非常耗时。  
2，在一主一从或者一主多从的情况下，如果主服务器挂了，单点问题没有得到解决。如果每次都是手动把之前的从服务器切换成主服务器，这个比较费时费力，还会造成一定时间的服务不可用。

# 可用性保证之Sentinel #

## sentinel原理 ##

如何实现主从的自动切换？ 我们思路：  
创建一台监控服务器来监控所有Redis服务节点的状态，比如，master节点超过一定时间没有给监控服务器发送心跳报文，就把master标记为下线，然后把某一个slave变成master。应用每一次都是从这个监控服务器拿到master的地址。  
问题是：如果监控服务器本身出问题了怎么办？那我们就拿不到master的地址了，应用也没有办法访问。

从Redis2.8版本起，提供了一个稳定版本的Sentinel（哨兵），用来解决高可用的问题。它是一个特殊状态的redis实例。  
我们会启动一个或多个Sentinel的服务（通过src/redis-sentinel）,它本质上只是一个运行在特殊模式之下的Redis，Sentinel通过info命令得到被监听Redis机器的master，slave等信息。

注意：Sentinel本身没有主从之分，  
概念梳理：master，slave（redis group），sentinel，sentinel集合

## 服务下线 ##

Sentinel默认以每秒钟1次的频率向Redis服务节点发送Ping命令。如果在down-after-milliseconds内都没有受到有效服务，Sentinel会将该服务器标记为下线（主观下线）。  
这个时候Sentinel节点会继续询问其他的Sentinel节点，确认这个节点是否下线，如果多数Sentinel节点都认为master下线，master才真正确认被下线（客观下线），这个时候就需要重新选举master。

## 故障转移 ##

如果master被标记为下线，就会开始故障转移流程。  
既然有这么多的Sentinel节点，由谁来做故障转移的事情呢？  
故障转移流程的第一步就是在Sentinel集群选择一个Leader，由Leader完成故障转移流程。Sentinle通过Raft算法，实现Sentinel选举。

## Ratf算法 ##

在分布式存储系统中，通常通过维护多个副本来提高系统的可用性，那么多个节点之间必须要面对数据一致性的问题。Raft的目的就是通过复制的方式，使所有节点达成一致，但是这么多节点，以哪个节点的数据为准呢？所以选择出一个Leader。

大体上有两个步骤：领导选举，数据复制  
Raft是一个共识算法（consensus algorithm）。比如比特币之类的加密货币，就需要共识算法。Spring Cloud的注册中心解决方案Consul也用到Raft协议。  
Raft的核心思想：先到先得，少数服从多数。

## 故障转移 ##

问题：怎么让一个原来的slave节点成为主节点？  
1，选出Sentinel Leader之后，由Sentinel Leader向某个节点发送slaveof no one命令，让它成为独立节点。  
2，然后向其他节点发送slaveof x.x.x.x xxxx（本机服务），让他们成为这个节点的子节点，故障转移完成。

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

## Sentinel的功能总结 ##

监控：Sentinel会不断检查主服务器和从服务器是否正常运行。  
通知：如果某一个被监控的实例出现问题，Sentinel可以通过API发出通知。  
自动故障转移（failover）：如果主服务器发生故障，Sentinel可以启动故障转移过程。把某台服务器升级为主服务器，并发出通知。  
配置管理：客户端连接到Sentinel，获取当前的Redis主服务器的地址。

## 哨兵机制的不足 ##

主从切换的过程中会丢失数据，因为只有一个masteer。  
只能单点写，没有解决水平扩容的问题。  
如果数据量非常大，这个时候我们需要多个master-slave的group，把数据分布到不同的group中。

# Redis 分布式方案 #

如果要实现Redis数据的分片，我们有三种解决方案。第一种是在客户端实现相关的逻辑，例如用取模或者一致性哈希对key进行分片，查询和修改都该先修改key的路由。  
第二种是把做分片处理的逻辑抽取出来，运行一个独立的代理服务，客户端连接到这个代理服务，代理服务做请求的转发。  
第三种就是基于服务端实现。

## 客户端 Sharding ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70]  
Jedis客户端提供了Redis Sharding 的方案，并且支持连接池。

使用ShardedJedis之类的客户端分片代码的优势是配置简单，不依赖于其他中间件，分区的逻辑可以自己定义，比较灵活，但是基于客户端的方案，不能实现动态的服务增减，每个客户端需要自行维护分片策略，存在重复代码。  
第二种思路就是把分片的代码抽取出来，做成一个公共服务，所有客户端都连接到这个代理层。由代理层来实现请求和转发。

# 代理Proxy #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 1]  
典型的代理分区方案由Twitter开源的Twemproxy和国内的豌豆荚开源的Codis。

## Twemproxy的优点 ##

https://github.com/twitter/twemproxy`https://github.com/twitter/twemproxy`  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 2]  
Twemproxy的优点：比较稳定，可用性高。  
不足：  
1，出现故障不能自动转移，架构复杂

## Codis ##

[https://github.com/CodisLabs/codis][https_github.com_CodisLabs_codis]  
codis 是一个代理中间件，用Go语言开发的。  
功能：客户端连接Codis和连接Redis没有区别。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 3]  
分片原理：codis把所有的key分成了N个槽（例如1024），每个槽对应一个分组，一个分组对应于一个或者一组Redis实例。Codis对key进行CRC32运算，得到一个32位的数字，然后模以N（槽的个数），得到余数，这个就是key对应key对应的槽，槽后面就是Redis实例。比如4个槽。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 4]  
Codis的槽位映射关系是保存在Proxy中的，如果要解决单点的问题，Codis也要做集群部署，多个Codis节点怎么同步槽和实例的关系呢？需要运行一个Zookeeper（或etcd/本地文件）。

在新增节点的时候，可以为节点指定特定的槽位。Codis也提供了自动均衡策略。  
Codis不支持事务，其他的命令也不支持。

[https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported\_cmds.md][https_github.com_CodisLabs_codis_blob_release3.2_doc_unsupported_cmds.md]  
获取数据原理（mget）：在Redis中的各个实例里获取到符合的key，然后在汇总到codis中。  
codis是第三方提供的分布式解决方案，在官方的集群功能稳定之前，codis也得到了了大量的应用。

## Redis Cluster ##

Redis Cluster是在Redis 3.0的版本正式推出的，用来解决分布式的需求，同时也可以实现高可用。跟Codis不一样，它是去中心化的，客户端可以连接到任意一个可用的节点。

数据分片有几个关键的问题需要解决：  
1，数据怎么相对均匀地分片  
2，客户端怎么访问到相应的节点和数据  
3，从新分片的过程，怎么保证正常服务

### 架构 ###

Redis Cluster可以看成 是由多个Redis实例组成的数据集合。客户端不需要关注数据的子集到底存储在哪个节点，只需要关注这个集合整体。

以3主3从为例，节点之间两两交互，共享数据分片、节点状态等信息。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 5]

### 数据分布 ###

如果是希望数据分布相对均匀的话，我们首先可以考虑哈希后取模。

#### 哈希后取模 ####

例如，hash（key）%N,根据余数，决定映射到哪一个节点。这种方式比较简单，属于静态的分片规则。但是一旦节点数量变化，新增或者减少，由于取模的N发生变化，数据需要重新分布，  
为了解决这个问题，我们又有了一致性哈希算法。

#### 一致性哈希 ####

一致性哈希的原理：  
把所有的哈希值空间组织成一个虚拟的圆环（哈希环），整个空间按顺时针方向组织。因为是环形空间，0和2^21-1是重叠的。  
假设我们有四台机器要哈希环来实现映射(分布数据)，我们先根据机器的名称或者IP计算哈希值，然后分布到哈希环中（红色圆圈）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 6]

现在有4条数据或者4个访问请求，对key计算后，得到哈希环中的位置（绿色圆圈）。沿哈希环顺时针找到第一个Node，就是数据存储的节点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 7]  
在这种情况下，新增了一个Node5节点，不影响数据的分布。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 8]  
删除了一个节点Node4，只影响相邻的一个节点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 9]

谷歌的MurmurHash就是一致性哈希算法。在分布式系统中，负载均衡、分库分表等场景中都有应用。

一致性哈希解决了动态增减节点时，所有数据都需要重新分布的问题，它只会影响到下一个相邻的节点，对其他节点没有影响。  
但是这样的一致性哈希算法有一个缺点，因为节点不一定是均匀分布的，特别是节点数比较少的情况下，所以数据不能得到均匀分布。解决这个问题的办法是引入虚拟节点（Virtual Node）。

eg：2个节点，5条数据，只有1条分不到node2,4条分不到Node1，不均匀。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 10]  
Node1设置了两个虚拟节点，Node2也设置了两个虚拟节点（虚线圆圈）这时候有3条数据分不到Node1,1条数据分不到Node2。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 11]

## Redis虚拟槽分区 ##

Redis既没有用哈希取模，也没有用一致性哈希，而是用虚拟槽来实现的。  
Redis创建了16384个槽（slot），每个节点负责一定区间的slot。比如Node1负责0-5460，Node2负责5461-10922，Node3负责10923-16383。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 12]  
Redis的每个Master节点维护一个16384位（2048bytes=2kb）的位系列，比如：系列的第0位是1，就代表第一个slot是它负责；系列的第一位是0，代表第二个slot不归他负责。  
对象分布到Redis节点上时，对key用CRC16算法再%16384，得到一个slot的值，数据落到负责这个slot的Redis节点上。

注意：key与slot的关系是永远不会变的，会变的只有slot和Redis节点的关系。

**问题：怎么让相关的数据落到同一个节点上？**  
比如有些multi key操作时不能跨节点的，如果要让某些数据分布到一个节点上，例如用户2673的基本信息和金融信息，怎么办？

在key里面加入\{hash tag\}即可。Redis 在计算槽编号的时候只会获取\{\}之间的字符串进行槽编号计算，这样由于上面两个不同的键，\{\}里面的字符串都是相同的，因此他们可以被计算出相同的槽。  
user\{2673\}base=…  
user\{2673\}fin=…

#### 高可用和主从切换原理 ####

当slave发现自己的master变为Fail状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，其过程如下：  
1，slave发现自己的master变为Fail。  
2，将自己记录的集群currentEpoch加1，并广播FailOver\_Auth\_Request信息  
3，其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FailOver\_auth\_ack,对每一个epoch只发送一次ack。  
4，尝试failover的slave收集FailOver\_auth\_ack  
5，超过半数后变成新Master  
6，广播Pong通知其他集群节点。  
Redis Cluster既能实现主从的角色分配，又能够实现主从切换，相当于集成了Replication和Sentinal的功能。

### 总结 ###

优势：  
1，无中心架构  
2，数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。  
3，可扩展性，可线性扩展到1000个节点（官方推荐不超过1000个），节点可动态添加或删除。  
4，高可用性，部分节点不可用时，集群仍然可用。通过增加Slave和standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用股票机制完成Slave到Master的角色提升。

不足：  
1，Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。  
2，节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。  
3，数据通过异步复制，不保证数据的强一致性。  
4，多个业务使用同一套集群时，无法统计区分冷热数据，资源隔离性差，容易出现相互影响的情况。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70]: /images/20220829/98863b1b1bbb4735b193d9118fefc308.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 1]: /images/20220829/ba2cf5f06b0b42e485ffe11aec3caa3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 2]: /images/20220829/a626c6e71ec442dfbd0e1613ee093363.png
[https_github.com_CodisLabs_codis]: https://github.com/CodisLabs/codis
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 3]: /images/20220829/a1927ce6d33c4cbdac8ced75e398e41e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 4]: /images/20220829/8ea14cb0d8a845878dc926fd381b6171.png
[https_github.com_CodisLabs_codis_blob_release3.2_doc_unsupported_cmds.md]: https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 5]: /images/20220829/4000aeb637f84c82b375901763eacda2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 6]: /images/20220829/0e2370b9c4e94dcf8bf44dad74bf6575.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 7]: /images/20220829/859a3ebde833481eb6eeb46c74a45043.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 8]: /images/20220829/7de98ba458bf4f879f5a954a9aacba06.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 9]: /images/20220829/f4063ad49da444c59f2d205018fc605d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 10]: /images/20220829/659791a6e0014fcf8404c80e000967a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 11]: /images/20220829/d7e391aa698b4285946634ef18e57536.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 12]: /images/20220829/bae54b63c97849ad9c30d5e4fd2db947.png