Redis在互联网大数据平台有着广泛的应用,主要被用来缓存热点数据,避免海量请求压垮数据库,同时可以提升服务节点的响应速度和并发量。随着数据量的增多,由于redis是占用单台物理机或虚机的内存,内存资源是有限的,要动态地扩容缩容,就需要用到redis集群。redis集群的架构方案经历了一系列演变和改良的过程,本文介绍了四种主流的redis架构方案。

客户端分片

redis集群主流架构方案分析-LMLPHP

  • 优点

不使用第三方中间件,实现方法和代码可以自己掌控并且可随时调整。这种分片性能比代理式更好(因为少了分发环节),分发压力在客户端,无服务端压力增加

  • 缺点

不能平滑地水平扩容,扩容/缩容时,必须手动调整分片程序,出现故障不能自动转移,难以运维

Twemproxy

redis集群主流架构方案分析-LMLPHP

  • 优点

运维成本低。业务方不用关心后端 Redis 实例,跟操作 Redis 一样。Proxy 的逻辑和存储的逻辑是隔离的

  • 缺点

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

b. 进行扩容/缩容时候,部分数据可能会失效,需要手动进行迁移,对运维要求较高,而且难以做到平滑的扩缩容

c. 出现故障,不能自动转移,运维性很差

Redis Cluster

redis集群主流架构方案分析-LMLPHP

  • 优点

a. 无中心节点

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

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

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

色的提升)

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

  • 缺点

a. 严重依赖外部 Redis-Trib

b. 缺乏监控管理

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

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

e. Gossip 消息的开销

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

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

Proxy + Redis Cluster

redis集群主流架构方案分析-LMLPHP

  • 优点

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.进行扩容/缩容时候对运维要求较高,而且难以做到平滑的扩缩容

实际项目中该如何选型呢?

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

大意就是目前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->代理->redis cluster,一定规模后基本都采用这种方式。

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

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

本文转自:https://www.toutiao.com/a6578325881486311939/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1531664683&app=news_article&utm_source=mobile_qq&iid=37343837404&utm_medium=toutiao_android

04-07 02:27
查看更多