每日一博 | Redis 集群演进探讨和总结
Redis为什么需要集群?
首先Redis单实例主要有单点,容量有限,流量压力上限的问题。
Redis单点故障,可以通过主从复制replication
,和自动故障转移sentinel
哨兵机制。
但Redis单Master
实例提供读写服务,仍然有容量和压力问题,因此需要数据分区,构建多个Master
实例同时提供读写服务(不仅限于从replica
节点提供读服务)。
那么就需要一定的机制保证数据分区。这样能充分把容量分摊到多台计算机,或能充分利用多核计算机的性能。
并且数据在各个主Master节点间不能混乱,当然最好还能支持在线数据热迁移的特性。
探讨数据分区方案
针对数据分区,一般来说,分为两个大类:
- 逻辑拆分: 逻辑上能拆分,比如 Redis 中的 M1 节点 存储 A服务需要的业务数据,而 Redis 中的 M2 节点存储 B服务需要的业务数据。
- 数据分区: 当逻辑上不能拆分,那么只能按数据来拆分,需要保证客户端读和写数据一致。 因此需要一个高效快速的数据结构来路由对应的
Master
节点。 最容易想到的就是类比 Java 中的HashMap
, 采用 哈希算法,快速找到,快速设置。 这里有四种方式,分别是固定取模,随机,哈希一致性,哈希槽。
固定取模
假设有三个 Master,配置IP 和权重如下:
Real Server IP | weight |
---|---|
10.0.2.21 | 1 |
10.0.2.22 | 2 |
10.0.2.23 | 3 |
那么会根据每一个real Server 及其权重虚拟出对应权重 weight 个的虚拟vritual server节点,映射关系会是:
Real Server IP | virtual server |
---|---|
10.0.2.21 | 1 |
10.0.2.22 | 2,3 |
10.0.2.23 | 4,5,6 |
一个 key 存储在那个虚拟vritual server节点,通过哈希hash算法:
virtual_server_index = hash(key) % (total_virtual_weight)
假设某个key,它的 hash 值是 10,那么以上: 10%6=4,将落到 10.0.2.23 这个真实的 Master上。
- 缺点 因为取模的模数是固定的,当新增或删除 master节点时,所有的数据几乎要全部洗牌,几乎需要重新迁移数据(而且相当麻烦),无法做到在线数据热迁移。 意味着Redis在此种用法下,只能当缓存,不能当存储数据库!
随机
随机选取一个存储和访问。 一般结合 list
,用于非顺序性要求的消息队列场景。
- 缺点: 使用场景比较单一。 并且由于随机性问题,导致持久化存在不可靠性。Redis在此种用法下,也只能当缓存,不能当存储数据库!
一致性哈希
一致性哈希算法(Consistent Hashing
)最早在论文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出。 简单来说,一致性哈希将整个哈希值空间组织成一个虚拟的圆环,如假设某哈希函数H的值空间为0-2^32-1(即哈希值是一个32位无符号整形),整个哈希空间环如下:
-
1.有一个HASH环,环上每个节点都是一个自然数,从0开始顺时针递增,直到2^32-1,最后回到0
-
2.真实节点 M1 M2 M3 通过 hash(IP 或主机名)确定在哈希环上的位置
-
3.当客户端请求时,首先 hash(key) 确定在哈希环上的位置,然后顺时针往后找,找到的第一个真实节点,就是客户端需要请求访问的真实主机
-
优点: 哈希一致性其实是对固定取模的一种优化。
- (1)扩展性:当增加节点时,只会影响顺时针的真实节点(此部分数据比较难迁移),而不是影响全部的节点。
- (2)容错性:当节点宕机或删除节点时,只会影响逆时针的真实节点,而不是影响全部的节点。
- (3)平衡性:当哈希算法的节点过少时,会可能造成某些服务器的数据存储较多,而另外一些存储较少,造成数据倾斜,当节点足够多时,这种现象得以缓解。 因此虚拟节点个数较大的时候,数据的平衡性得以保证。
-
缺点: 因为当增删节点时,需要重新计算受影响部分的节点中的key全部找出来,才能迁移,这个很麻烦!!! Redis在此种用法下,也只能当缓存,不能当存储数据库!
哈希槽(PreSharding)
这个跟哈希一致性很相似。 区别在于,它预先分配好真实节点管理的哈希槽(slot
),并存储管理起来,我们可以预先知道哪个master主机拥有哪些哈希槽(slot
),这里总数是16384。
127.0.0.1:7001> cluster nodes 2aaf59558f1b9f493a946a695e51711eb03d15f9 127.0.0.1:7002@17002 master - 0 1590126183862 2 connected 5461-10922 6439c3e9468fd2c545a63b3b9bfe658c5fc14287 127.0.0.1:7003@17003 master - 0 1590126181856 3 connected 10923-16383 340d985880c23de9816226dff5fd903322e44313 127.0.0.1:7001@17001 myself,master - 0 1590126182000 1 connected 0-5460
我们可以清晰看到Redis Cluster中的每一个master节点管理的哈希槽。 比如 127.0.0.1:7001 拥有哈希槽 0-5460, 127.0.0.1:7002 拥有哈希槽 5461-10922, 127.0.0.1:7003 拥有哈希槽 10923-16383。
➜ redis-cli -p 7001 127.0.0.1:7001> set a 1 (error) MOVED 15495 127.0.0.1:7003 ➜ redis-cli -p 7001 -c 127.0.0.1:7001> set a 1 -> Redirected to slot [15495] located at 127.0.0.1:7003 OK
-
我们看到的是master节点在 Redis Cluster中的实现时,都存有所有的路由信息。 当客户端的key 经过hash运算,发送
slot
槽位不在本节点的时候。- (1)如果是非集群方式连接,则直接报告错误给client,告诉它应该访问集群中那个IP的master主机。
- (2)如果是集群方式连接,则将客户端重定向到正确的节点上。 注意这里并不是127.0.0.1:7001 帮client去连接127.0.0.1:7003获取数据的,而是将客户端请求重定向了。
-
优点: 继承并增强一致性哈希的容错性,扩展性,以及平衡性。 Redis在此种用法下,可以当缓存,也能当存储数据库!
-
这里Redis给出更详细的说明:https://redis.io/topics/partitioning
具体方案
以下列表为按照出现的先后顺序排列:
方案 | 描述 | 数据分区支持策略 | 分布式 | 在线数据热迁移 |
---|---|---|---|---|
twemproxy | twitter 开源的redis代理中间件,不修改redis源码 https://github.com/twitter/twemproxy | 存在modula(固定取模)、 random (随机)、ketama(哈希一致性)三种可选的配置 | 本身是单点的,可以通过keepalived等保证高可用 | 不支持,无法平滑地扩容/缩容 |
Redis Cluster | 官方提供的集群方案 | 采用预先分片(PreSharding),即哈希槽方式,存储在每一个master节点上 | 没有proxy代理层,客户端可以连接集群中的任意master节点 | 提供客户端命令redis-cli --cluster reshard ip port 按哈希槽迁移指定节点的数据 |
codis | 豌豆荚开源的redis代理中间件,修改了redis源码 https://github.com/CodisLabs/codis | 采用预先分片(PreSharding),即哈希槽方式,存储在ZooKeeper上 | 集群部署,部署相对复杂 | 支持数据热迁移 |
- Redis Cluster :一般生产环境量不大,且采用
Spring
提供的RedisTemplate
之类封装好的 fat client ,可以采用 - redis6.0后,官方也推出Redis Cluster的proxy方案 (https://github.com/RedisLabs/redis-cluster-proxy),只是尚为新,且处于beta阶段(2020.5处于1.0beta版本),不成熟。但未来可期,毕竟是官方支持的。)
- 目前如果生产环境量大,但尚无研发能力,可以选用 codis
@SvenAugustus(https://www.flysium.xyz/)
更多请关注微信公众号【编程不离宗】,专注于分享服务器开发与编程相关的技术干货:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MrDoc 0.5.2 发布,优化 Markdown 编辑器,新增 Echarts 图表
2020年5月24日,Python 开源在线文档系统 MrDoc 发布了 0.5.2 版本。这个版本中主要更新了如下内容: 升级 marked 版本,解决了众多 Editor.md Markdown编辑器的渲染解析问题。 升级思维导图组件 markmap-lib 版本。 新增 Markdown 编辑器对 Echarts 图表的支持,可以在编辑器中插入 Echarts图表。 新增文档的复制移动功能,文档可以复制或移动到其他文集。 优化个人中心图片管理和文档模板管理的默认排序; 优化注册邀请码最大使用次数的验证; 优化了配置路径和配置项,支持在配置文件中设置Chromium启动参数; 增强了代码的安全性 目前以下平台客户端正在开发中: Android 客户端 Windows免安装个人使用包
- 下一篇
微软开源早期编程语言 GW-BASIC
微软通过一篇博客文章宣布开放GW-BASIC的源代码。并表示,自从MS-DOS 1.25 和 2.0 开源后,社区中要求同样开源 BASIC 语言的呼声颇高。因此微软选择将 1983 年以来的 8088 汇编语言开源出来,但仅作历史参考和教育用途,不再接收任何修改源码的拉取请求。 GW-BASIC 是 BASIC 的一个方言版本,诞生于1983 年 2 月 10 日,作为MS-DOS的一个组成部分而问世。根据微软的介绍,它是从 IBM Advanced BASIC/BASICA 衍生而来的 BASIC 解释器,本身也是 Microsoft BASIC 的端口。 GW-BASIC 和微软提供给IBM PC的BASICA完全兼容,不同的是,后者依赖于ROM中的 BASIC 解释器,而前者并不需要。所以,GW-BASIC 能在众多 IBM PC 兼容机器上运行。在 70 和 80 年代后期,BASIC 被移植到许多 OEM 平台上,并适应了当时流行的几种处理器,包括 8088、6502、6809,Z80 等。 就像那个年代的所有其他软件(例如 MS-DOS)一样,GW-BASIC 的源代码 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用