Redis集群方案比较以及数据分区方式

最新推荐文章于 2023-04-18 10:47:32 发布

huaishu

最新推荐文章于 2023-04-18 10:47:32 发布

阅读量1k

点赞数 1

分类专栏： Redis

本文链接：https://blog.csdn.net/huaishu/article/details/104005864

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

很多年前接触Redis，还只有单机版，主要用途就是当缓存使用，主要对手就是Memcached，经过多年发展已经实现多种集群方案。

Redis集群模式通常具有高可用、可扩展性、分布式、容错等特性。Redis 分布式方案一般有两种：

客户端分区方案 Redis Sharding

客户端分区方案的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis 多实例集群方法。Java 的 Redis 客户端驱动库 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及结合缓存池的 ShardedJedisPool。
服务端分区方案

Redis Cluster 是Redis的分布式解决方案，在 3.0 版本正式推出，有效地解决了 Redis 在分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用 Cluster 架构方案达到负载均衡的目的。

数据分布方式

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集。

单机数据库数据分布主要体现在数据索引上，通过索引快速定位数据，索引方式分为BTREE和HASH。

数据分布通常有哈希分区和顺序分区两种方式：

方式	特点	相关产品
哈希分区	离散程度好，数据分布与业务无关，无法顺序访问	Redis Cluster，Cassandra，Dynamo
顺序分区	离散程度易倾斜，数据分布与业务相关，可以顺序访问	BigTable，HBase，Hypertable

Oracel数据库中分区表提供这2种分区方式，当存储日志数据时，可以按时间顺序作为分区键；当存储统计数据，如姓名等，可以使用哈希分区。顺序分区有利于范围范围查询，哈希分区有利于点查询。

1.节点取余分区

使用特定的数据，如 Redis的键或用户 ID，再根据节点数量N使用公式：hash（key）% N 计算出哈希值，用来决定数据映射到哪一个节点上。

优点

这种方式的突出优点是简单性，常用于数据库的分库分表规则。一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据容量，再根据负载情况将表迁移到其他数据库中。扩容时通常采用翻倍扩容，避免数据映射全部被打乱，导致全量迁移的情况。

缺点

当节点数量变化时，如扩容或收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。

2.一致性哈希分区

一致性哈希可以很好的解决稳定性问题，可以将所有的存储节点排列在收尾相接的Hash环上，每个key 在计算Hash后会顺时针找到临接的存储节点存放。而当有节点加入或退出时，仅影响该节点在Hash 环上顺时针相邻的后续节点。

优点

加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。

缺点

加减节点会造成哈希环中部分数据无法命中。当使用少量节点时，节点变化将大范围影响哈希环中数据映射，不适合少量数据节点的分布式方案。普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。

注意：因为一致性哈希分区的这些缺点，一些分布式系统采用虚拟槽对一致性哈希进行改进，比如 Dynamo 系统。

3.虚拟槽分区

虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，比如 Redis Cluster 槽范围是 0 ~ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽

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

由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

Redis集群

Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0~16383 整数槽内，计算公式：slot = CRC16（key）& 16383，每个节点负责维护一部分槽以及槽所映射的键值数据。

Redis集群的功能限制

key 批量操作支持有限。

类似 mset、mget 操作，目前只支持对具有相同 slot 值的 key 执行批量操作。对于映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上，因此不被支持。

key 事务操作支持有限。

只支持多key在同一节点上的事务操作，当多个 key分布在不同的节点上时无法使用事务功能。

key 作为数据分区的最小粒度

不能将一个大的键值对象如hash、list 等映射到不同的节点。

不支持多数据库空间

单机下的Redis可以支持16个数据库（db0 ~ db15），集群模式下只能使用一个数据库空间，即db0。

复制结构只支持一层

从节点只能复制主节点，不支持嵌套树状复制结构。

Multi-Key 限制的处理

对于多key场景，需要做好数据空间的设计，Redis Cluster 提供了一个 hash tag 的机制，可以让我们把一组 key 映射到同一个 slot。

例如：user1000.following 这个 key 保存用户 user1000 关注的用户；user1000.followers 保存用户 user1000 的粉丝。

这两个 key 有一个共同的部分 user1000，可以指定对这个共同的部分做 slot 映射计算，这样他们就可以在同一个槽中了。

使用方式：

{user1000}.following 和 {user1000}.followers

就是把共同的部分使用 { } 包起来，计算 slot 值时，如果发现了花括号，就会只对其中的部分进行计算。

Redis 一致性保证

Redis 并不能保证数据的强一致性。这意味这在实际中集群在特定的条件下可能会丢失写操作。

第一个原因是因为集群是用了异步复制. 写操作过程：

客户端向主节点B写入一条命令。
主节点B向客户端回复命令状态。
主节点将写操作复制给他得从节点 B1，B2 和 B3。

主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区，并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点，还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 。

Z1仍然能够向主节点B中写入，如果网络分区发生时间较短，那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了。

注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项。