redis集群主流架构专项方案分析.doc

redis集群主流架构方案分析

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

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

缺点

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

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

缺点

a. 代理层多了一次转发，性能有所损耗
b. 进行扩容/缩容时候，部分数据可能会失效，需要手动进行迁移，对运维要求较高，而且难以做到平滑扩缩容
c. 出现故障，不能自动转移，运维性很差
Redis Cluster优点

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优点

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官方文档中有以下这段话:The redis-cli cluster support is very basic so it always uses the fact that Redis Cluster nodes are able to redirect a client to the right node. A serious client is able to do better than that, and cache the map between hash slots and nodes addresses, to
directly use the right connection to the right node. The map is refreshed only when something changed in the cluster configuration, for example after a failover or after the system administrator changed 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官方文档
Codis是一整套缓存处理方案，包含高可用、数据分片、监控、动态扩态 etc.。
走是 Apps->代理->redis cluster，一定规模后基础全部采取这种方法。
方案3 自己独立开发redis智能用户端
关键实现redis slots管理，failover，一致性hash功效。
以上就是笔者在实际工作中总结和研究结果，能力所限，假如您有其它提议和好思绪，欢迎给我留言探讨。本头条号天天全部会更新互联网相关技术分享，欢迎大家订阅。