作者:贲绍华
爱可生研发中心工程师,负责项目的需求与维护工作。其他身份:柯基铲屎官。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
当我们只使用一台 Redis 实例也就是 Single 架构时,需要考虑一些非常实际的问题,如:单节点一但宕机则业务停摆、单节点的容量不可能是无限制的、性能同样存在瓶颈等......
集群架构模式最主要的三个目的就是:高可用、提升资源限制瓶颈、提升网络吞吐:
Redis Sentinel 是一个分布式系统, 可以在一个架构中运行多个 Sentinel 进程(progress)
这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,
以及选择哪个从服务器作为新的主服务器。
将数据通过对应的算法规则,自动分割数据到不同的节点上,每一个节点都是主,都承担一部分数据。
在整个集群的部分节点失败或者不可达的情况下依然能够继续处理命令。
数据的拆分可以依据AKF原则根据不同维度进行灵活拆分:
Redis使用的是epoll IO模型,单机吞吐量也足够优秀,但当业务流量单一入口不能兜住时则需要考虑分流策略了。
如:增加 slave 节点、使用 proxy 作为流量入口、Redis cluster、LVS等
灵活的架构能使业务侧不需要太关心具体到哪个节点,节点资源瓶颈如何。均使用统一流量入口即可。
此处的客户端指的就是业务侧,根据业务类型分类存取,自行维护一个 client to redis node 的映射关系或服务发现机制。
简单场景下这么做并不会有什么问题,但是也存在一些缺点,如:
Redis 也有一些优秀的 proxy ,它们在作为统一流量入口的同时也提供了一些非常实用的功能,如数据 sharding 。
根据一定规则使对应的key落到集群的不同节点上,下边简单介绍一下常见的redis proxy与分片的算法逻辑:
通过算法对key进行取模,决定最终需要在哪个节点上进行存取。
作为消息队列使用时候,可以将多个Redis实例组成Topic,生产者存入(lpush)数据,消费者消费(rpop)
一致哈希算法是对一组数进行取模运算的结果值组织成一个圆环,就像钟表一样,它可以被想象成带有60个刻度的圆,这个圆环被称为哈希环。
在移除或者添加一个服务器时,能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。
一致性哈希解决了简单哈希算法在分布式哈希表中存在的动态伸缩等问题。
操作步骤:
Redis Cluster没有使用一致性hash, 而是引入了哈希槽的概念。每一台实例都会分配对应的槽位,自带了算法与集群内所有槽位的记录,所以每一台都是主。
客户端随机地请求任意一个redis实例,然后由Redis将请求转发给正确的Redis节点。简单的说就是每一个节点的组成都是:数据+路由
为了方便理解,下边通过图解进行说明:
当使用Redis cluster架构时候:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。