目录

摘要:

官方文档:

enterprise:

cluster:

整体架构:

redis-cluster:

说明:

redis-enterprise:

说明:

对标企业版:

一.  借鉴企业版将数据节点和监控节点分离的策略, 而非cluster模式使用自身集群监控

二. 加入proxy, 并在proxy层做槽位分配

三. 把企业版的一堆开源或不开源的插件和存储引擎集成进去

开源模块:

不开源的模块:

摘要:

redis社区版提供了cluster分布式解决方案, 本文将社区版的cluster方案与redis企业版的集群方案进行对比/

官方文档:

enterprise:

Redis Enterprise Cluster Architecture | Redis

cluster:

Scaling with Redis Cluster | Redis

整体架构:

redis-cluster:

说明:

cluster模式中的任意节点, 都保持本集群所有的元信息
本分片存储的槽位, ip:port信息其他分片存储的槽位, ip:port信息各个节点间的主从关系各个节点的状态
cluster模式中任意两个节点都互相连接, 图中仅将slave与master进行连接, 目的是说明主从间关系. 但从节点依然与其他所有的cluster节点保持连接cluster模式内, master节点, 组成投票者, 承担节点的故障检测和完成failover功能
由于依赖quorum过半master投票, 所以集群正常failover依赖过半的master的正常工作
cluster模式下的节点任意两点互相心跳通信, 网络开销与节点数N成指数关系
官方建议不超过1000个节点

redis-enterprise:

说明:

 企业版的存储部署是开源的, 包括
单点redis, sentinel监控, cluster模式常规内置插件:
跨模块和节点操作 RedisGears:  https://github.com/RedisGears/RedisGears其他存储引擎:
GitHub - RedisTimeSeries/RedisTimeSeries: Time Series data structure for Redishttps://github.com/RedisGraph/RedisGraphhttps://github.com/RediSearch/RediSearchhttps://github.com/RedisAI/RedisAIhttps://github.com/RedisJSON/RedisJSON
集群模式使用了一种与cluster完全不同的模式, 更类似于哨兵的数据存储与监控分离的模式
redis-server服务不存储任何元信息, shard-nothing
不存储本节点和其他节点的槽位不存储其他节点信息, 不检测其他节点状态, 也不参与failover处理
由单独的clusterManager监控模块, 对故障节点做监控, 并完成failover
由于redis-server的数据节点不再互相交互, 也不参与节点故障检测和failover, 获得了以下优势
redis-server数据节点可以无限扩充, 而cluster模式的节点扩充将对网络io开销造成指数影响, 存在上限
官方建议cluster节点数限制在1000以内
由于redis-server不再参与故障检测和failover, 而是由独立的监控服务进行, 可以避免cluster模式下必须quornum过半master正常运行的限制
redis集群的故障检测和failover仅与clusterManager模块相关, redis-server数据节点可任意failiover
将多个槽位节点, 划为一个HS组, 由一个proxy负责转发
作为对比, cluster模式下, proxy转发是以单个redis-server承载的槽位进行, 企业版将多个redis-server承载的槽位划分了组
企业版开发了zeroLatencyProxy, 而clulster需要借助第三方proxy, 比如使用predixy
zeroLatencyProxy本身维护了后端节点, 在proxy层做key路由转发控制predixy是从redis-cluster自身读取出所有的后端节点, 并处理ASK和MOVED指令重定向
企业版加强了自从redis6.0开始引入的ACL权限控制

对标企业版:

一.  借鉴企业版将数据节点和监控节点分离的策略, 而非cluster模式使用自身集群监控

具体便是使用例如哨兵这样的外部监控, 来监控redis数据节点并完成failover.  

哨兵本身便可监控多个redis主从服务, 已完成了大部分核心工作对于哨兵的修改更多的是数据的安全性层面
如何防止脑裂: redis主服务和哨兵服务存在网络分区
quornum投票zkfc的做法, 从节点升主前尝试刺死主服务
如果哨兵和从服务都与主服务存在网络分区, 那么将无法刺死主服务一旦刺死主服务, 必须添加策略, 待完成failover后, 将旧主服务重新拉起, 否则新主将没有从服务
此处属于备库重建范围, 仅当服务挂掉, pod依然正常时, 所需要做的备库重建工作. 此处不再详细展开

二. 加入proxy, 并在proxy层做槽位分配

redis-server数据节点, 仅处理:

 存储数据slaveof主从关系, 完成主从数据的复制

三. 把企业版的一堆开源或不开源的插件和存储引擎集成进去

不开源的要么找个社区版别人写的, 要么自己写

开源模块:

跨模块和节点操作 RedisGears:  https://github.com/RedisGears/RedisGears其他存储引擎:
https://github.com/RedisTimeSeries/RedisTimeSerieshttps://github.com/RedisGraph/RedisGraphhttps://github.com/RediSearch/RediSearchhttps://github.com/RedisAI/RedisAIhttps://github.com/RedisJSON/RedisJSON

不开源的模块:

 无冲突复制数据类型CRDT:

Diving into CRDTs | Redis

Active-Active Geo-Distribution (CRDTs-based) | Redis

When to use a CRDT-based database | InfoWorld

开源社区的一个实现分支:
https://github.com/elem-azar-unis/CRDT-Redis