Redis集群架构及对比的示例

48次阅读

没有评论

共计 3007 个字符，预计需要花费 8 分钟才能阅读完成。

自动写代码机器人，免费开通

丸趣 TV 小编给大家分享一下 Redis 集群架构及对比的示例，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

1、Redis3.0

· 优点

a. 无中心节点

b. 数据按照 slot 存储分布在多个 Redis 实例上

c. 平滑的进行扩容 / 缩容节点

d. 自动故障转移(节点之间通过 Gossip 协议交换状态信息, 进行投票机制完成 Slave 到 Master 角色的提升)

e. 降低运维成本，提高了系统的可扩展性和高可用性

（推荐（免费）：redis）

· 缺点

a. 严重依赖外部 Redis-Trib

b. 缺乏监控管理

c. 需要依赖 Smart Client(连接维护, 缓存路由表, MultiOp 和 Pipeline 支持)

d. Failover 节点的检测过慢，不如“中心节点 ZooKeeper”及时

e. Gossip 消息的开销

f. 无法根据统计区分冷热数据

g. Slave“冷备”，不能缓解读压力

2、Proxy +Redis Cluster

· 优点

Smart Client：

a. 相比于使用代理，减少了一层网络传输的消耗，效率较高;

b. 不依赖于第三方中间件，实现方法和代码自己掌控，可随时调整。

Proxy：

a. 提供一套 HTTP Restful 接口，隔离底层存储。对客户端完全透明，跨语言调用。

b. 升级维护较为容易，维护 Redis Cluster，只需要平滑升级 Proxy。

c. 层次化存储，底层存储做冷热异构存储。

d. 权限控制，Proxy 可以通过秘钥控制白名单，把一些不合法的请求都过滤掉。并且也可以控制用户请求的超大 Value 进行控制和过滤。

e. 安全性，可以屏蔽掉一些危险命令，比如 Keys、Save、Flush All 等。

f. 容量控制，根据不同用户容量申请进行容量限制。

g. 资源逻辑隔离，根据不同用户的 Key 加上前缀，来进行资源隔离。

h. 监控埋点，对于不同的接口进行埋点监控等信息。

· 缺点

Smart Client：

a. 客户端的不成熟，影响应用的稳定性，提高开发难度。

b. MultiOp 和 Pipeline 支持有限。

c. 连接维护，Smart 客户端对连接到集群中每个结点 Socket 的维护。

Proxy：

a. 代理层多了一次转发，性能有所损耗。

b．进行扩容 / 缩容时候对运维要求较高，而且难以做到平滑的扩缩容

3、技术选型

redis 官方文档中有如下这段话:

The redis-cli cluster support is very basic so it alwaysuses the fact that Redis Cluster nodes are able to redirect a client to theright node. A serious client is able to do better than that, and cache the map betweenhash slots and nodes addresses, to directly use the right connection to theright node. The map is refreshed only when something changed in the clusterconfiguration, for example after a failover or after the system administratorchanged the cluster layout by adding or removing nodes.

大意就是目前 redis cluster 官方客户端功能简陋，依赖于 redis 节点重定向去到集群中找到数据所在的 redis 实例。需要有一个更完善的客户端，能够实现一致性 hash，failover 和集群管理功能。因此使用官方的 redis cluster 客户端不是一个明智的选择，本文提供 3 种方案供大家参考，如果有不合理的地方，欢迎大家与我共同探讨。

方案 1 使用 nginx 开发(OpenResty 方式)

原因如下:

a. 单 Master 多 Work 模式，每个 Work 跟 Redis 一样都是单进程单线程模式，并且都是基于 Epoll 事件驱动的模式。

b. Nginx 采用了异步非阻塞的方式来处理请求，高效的异步框架。

c. 内存占用少，有自己的一套内存池管理方式。将大量小内存的申请聚集到一块，能够比 Malloc 更快。减少内存碎片，防止内存泄漏。减少内存管理复杂度。

d. 为了提高 Nginx 的访问速度，Nginx 使用了自己的一套连接池。

e. 最重要的是支持自定义模块开发。

f. 业界内，对于 Nginx，Redis 的口碑可称得上两大神器。性能都很好。

方案 2 codis（豌豆荚采用的基于代理的 redis 集群方案)

参考 codis 官方文档 https://github.com/CodisLabs/codis

Codis 是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。

走的是 Apps- 代理 - rediscluster，一定规模后基本都采用这种方式。

方案 3 自己独立开发 redis 智能客户端

主要实现 redis slots 管理，failover，一致性 hash 功能。

4、Redis 3.0 集群

Redis 3.0 集群采用了 P2P 的模式，完全去中心化。Redis 把所有的 Key 分成了 16384 个 slot，每个 Redis 实例负责其中一部分 slot。集群中的所有信息(节点、端口、slot 等)，都通过节点之间定期的数据交换而更新。

Redis 客户端在任意一个 Redis 实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。

Redis 3.0 集群的工作流程如下图所示。

Redis 集群内的机器定期交换数据，工作流程如下：

（1）Redis 客户端在 Redis2 实例上访问某个数据；

（2）在 Redis2 内发现这个数据是在 Redis3 这个实例中，给 Redis 客户端发送一个重定向的命令；

（3）Redis 客户端收到重定向命令后，访问 Redis3 实例获取所需的数据。

Redis 3.0 的集群方案有以下两个问题：

1) 一个 Redis 实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署 Redis 就行，不像 Codis 有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，若哪天 Redis 集群出了什么严重的 Bug，就只能回滚整个 Redis 集群。

2) 对协议进行了较大的修改，对应的 Redis 客户端也需要升级。升级 Redis 客户端后谁能确保没有 Bug？而且对于线上已经大规模运行的业务，升级代码中的 Redis 客户端也是一个很麻烦的事情。

5、Redis4.0