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

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节点重定向去到集群中找到数