技术分享 | Redis 集群架构解析

作者:贲绍华

爱可生研发中心工程师,负责项目的需求与维护工作。其他身份:柯基铲屎官。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


一、集群架构的一些基本概念

当我们只使用一台 Redis 实例也就是 Single 架构时,需要考虑一些非常实际的问题,如:单节点一但宕机则业务停摆、单节点的容量不可能是无限制的、性能同样存在瓶颈等......

集群架构模式最主要的三个目的就是:高可用、提升资源限制瓶颈、提升网络吞吐:

1.1 高可用 - Sentinel

Redis Sentinel 是一个分布式系统, 可以在一个架构中运行多个 Sentinel 进程(progress)

这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。

a1299e1776c06b3c46f560d358d96a05.png

1.2 提升资源限制瓶颈 - 数据分区存储(Partitioning)

将数据通过对应的算法规则,自动分割数据到不同的节点上,每一个节点都是主,都承担一部分数据。

在整个集群的部分节点失败或者不可达的情况下依然能够继续处理命令。

数据的拆分可以依据 AKF 原则根据不同维度进行灵活拆分:

d3e4db0dbadc726277cef464454a6999.png

1.3 提高网络吞吐

Redis 使用的是 epoll IO 模型,单机吞吐量也足够优秀,但当业务流量单一入口不能兜住时则需要考虑分流策略了。

如:增加 slave 节点、使用 proxy 作为流量入口、Redis cluster、LVS等

灵活的架构能使业务侧不需要太关心具体到哪个节点,节点资源瓶颈如何。均使用统一流量入口即可。

二、客户端分区

此处的客户端指的就是业务侧,根据业务类型分类存取,自行维护一个 key - redis node 的映射关系或服务发现机制。

简单场景下这么做并不会有什么问题,但是也存在一些缺点,如:

  • 存取规则需要统一,需要考虑扩缩容时业务逻辑调整的影响面

  • 业务其实并不清楚 Redis 节点机器的瓶颈

  • 每个客户端都需要连接所有的 Redis 节点

三、代理分区

Redis 也有一些优秀的 proxy ,它们在作为统一流量入口的同时也提供了一些非常实用的功能,如数据 sharding 。

根据一定规则使对应的 key 落到集群的不同节点上,下边简单介绍一下常见的 redis proxy 与分片的算法逻辑:

a99f6455985a36ed5f839c965fd7beea.png

3.1 Modula [ 根据算法 + 取模存取 ]

通过算法对key进行取模,决定最终需要在哪个节点上进行存取。

  • 缺点:可能会出现数据分布节点不均匀的情况,机器扩缩容时需要调整取模策略

3.2 Random [ 随机存取 ]

作为消息队列使用时候,可以将多个Redis实例组成Topic,生产者存入(lpush)数据,消费者消费(rpop)

  • 缺点:可能会出现数据分布节点不均匀的情况

3.3 Ketama [ 一致性哈希 ]

一致哈希算法是对一组数进行取模运算的结果值组织成一个圆环,就像钟表一样,它可以被想象成带有60个刻度的圆,这个圆环被称为哈希环。在移除或者添加一个服务器时,能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。

一致性哈希解决了简单哈希算法在分布式哈希表中存在的动态伸缩等问题。

  • 优点:增加节点可以分担其他节点存储压力,因为没有取模过程不会影响其他节点的存储策略

  • 缺点:新增节点会造成一小部分数据不能命中(此时应再取附近的2个节点查看数据是否存在)

操作步骤:

  1. 规划一个哈希环,环上node hash后的槽位为物理节点,其余为虚拟节点

  2. 将所有物理节点标记起来

  3. 数据(key)加进来时通过hash过后查询该槽位是否为物理节点,如果是虚拟节点,则找寻离它最近的物理节点后存入

四、Redis Cluster(无中心架构)

Redis Cluster没有使用一致性hash, 而是引入了哈希槽的概念。每一台实例都会分配对应的槽位,自带了算法与集群内所有槽位的记录,所以每一台都是主。客户端随机地请求任意一个redis实例,然后由Redis将请求转发给正确的Redis节点。简单的说就是每一个节点的组成都是:数据+路由

  • 优点:扩缩容方便,Redis自带了工具与脚本对于Redis cluster架构也有很好的支持

  • 缺点:客户端连接直接压在了实例自身(可以在上层增加 proxy),删除重定向也会造成过多的请求转发与处理流程

为了方便理解,下边通过图解进行说明:

3fa27ca27d6d46496eb06a8b0ebec198.pngcbeb664c9db315febbb84d907f863e51.png

五、其他

当使用 Redis cluster 架构时候:

  • 涉及多个 key 的操作通常不会被支持。例如不能对两个集合求交集,因为他们可能被存储到不同的 Redis 实例(KEYS *、WATCH、MULTI...)

  • 同时操作多个 key ,则不能使用 Redis 事务

本文关键字:#Redis集群# #Redis分区#


文章推荐:

技术分享 | TiUP工具 - TiDB集群滚动升级核心流程解析

故障分析 | OceanBase Proxy 无法连接 OBserver 集群

技术分享 | Xtrabackup 不备份 binlog 怎么保证一致性?

技术分享 | 怎么找到上锁的 SQL 语句


关于SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者,支持多场景审核,支持标准化上线流程,原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。

SQLE 获取

类型地址
版本库https://github.com/actiontech/sqle
文档https://actiontech.github.io/sqle-docs-cn/
发布信息https://github.com/actiontech/sqle/releases
数据审核插件开发文档https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html

更多关于 SQLE 的信息和交流,请加入官方QQ交流群:637150065...

8b4ad4ab6c1613b75df82f791aa20fb6.jpeg

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值