Redis Cluster集群应用与原理（上）

2022-02-23 03:57:11

与memcached客户端支持分布式方案不同，Redis更倾向于在服务端构建分布式存储

Redis Cluster集群应用与原理（上）

Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，没有中心节点，具有线性可伸缩的功能。节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。

在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个hash槽，每个节点上可以存储一个或多个hash槽，也就是说当前Redis Cluster支持的最大节点数就是4096。

Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER

整体设计可总结为：

数据hash分布在不同的Redis节点实例上
M/S的切换采用Sentinel
写：只会写master Instance，从sentinel获取当前的master Instance
读：从Redis Node中基于权重选取一个Redis Instance读取，失败/超时则轮询其他Instance；Redis本身就很好的支持读写分离，在单进程的I/O场景下，可以有效的避免主库的阻塞风险
通过RPC服务访问，RPC server端封装了Redis客户端，客户端基于Jedis开发

在数据一致性问题上，Redis没有提供CAS操作命令来保障高并发场景下的数据一致性问题，不过它却提供了事务的功能

Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行）。

但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）

Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行

1 数据分布算法

决定了在多master节点时，数据如何分布到这些节点。

Redis cluster下，每个Redis要开放两个端口，比如：

cluster bus的通信，用来故障检测，配置更新，故障转移授权。cluster bus用另一种二进制协议 - gossip，用于节点间高效数据交换，占用更少网络带宽和处理时间。

计算指定 key 的 hash值，然后对节点数量(3)取模。0、1、2三个结果打到对应mater node。

一个mater宕机，所有请求过来，会发现都基于最新的2个master取模，尝试去取数据。导致大部分请求无法拿到有效缓存，流量涌入DB。

高井发场景下不可接受。并发下对节点3的流量无法走缓存，导致全部走DB，DB就会被压垮。

任一master宕机，大量数据就需重新计算再写入缓存。

某mater宕机，就导致数据全部失效。全部要重新对剩下2台master取模，再分布到其它节点。

自动缓存迁移、自动负载均衡。

可能集中在某个hash区间值多，导致大量数据涌入同个master，造成master热点问题，导致性能瓶颈。

同样是计算指定 key 的 hash值，然后用hash值在圆环对应各点(每点都有个hash值)对比，看hash值该落在这圆环的哪个部位。

key落在圆环后，顺时针寻找距离自己最近节点。

一致性hash算法保证任一master宕机，只有之前在那master上的数据会受影响，因为顺时针走，全部在之前master上找不到了。会顺时走到下个master，也找不到。

1/3的流量瞬间涌入DB，重新查询。几乎接近100%流量全部失效。

给每个master做均匀分布的虚拟节点。

这样在每个区间内，大量数据均匀分布到不同节点内，而非按顺时针顺序，全部涌入同一master。