一起看看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

(1)所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽；

(2)节点的Fail是通过集群中超过半数的节点检测失效时才生效；

(3)客户端与redis节点直连，不需要中间proxy层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可；

(4)redis-cluster把所有的物理节点映射到[0-16383]slot(插槽)上，cluster 负责维护node<->slot<->value。

Atas ialah kandungan terperinci 一起看看Redis集群架构及对比. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!