标签：定向 控制 透明 维护 failover open 扩展性 探讨 基本
Redis在互联网大数据平台有着广泛的应用，主要被用来缓存热点数据，避免海量请求压垮数据库，同时可以提升服务节点的响应速度和并发量。随着数据量的增多，由于redis是占用单台物理机或虚机的内存，内存资源是有限的，要动态地扩容缩容，就需要用到redis集群。redis集群的架构方案经历了一系列演变和改良的过程，本文介绍了四种主流的redis架构方案。
不使用第三方中间件，实现方法和代码可以自己掌控并且可随时调整。这种分片性能比代理式更好(因为少了分发环节)，分发压力在客户端，无服务端压力增加
不能平滑地水平扩容，扩容/缩容时，必须手动调整分片程序，出现故障不能自动转移，难以运维
运维成本低。业务方不用关心后端 Redis 实例，跟操作 Redis 一样。Proxy 的逻辑和存储的逻辑是隔离的
a. 代理层多了一次转发，性能有所损耗
b. 进行扩容/缩容时候，部分数据可能会失效，需要手动进行迁移，对运维要求较高，而且难以做到平滑的扩缩容
c. 出现故障，不能自动转移，运维性很差
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“冷备”，不能缓解读压力
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官方文档https://github.com/CodisLabs/codis
Codis是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。
走的是 Apps->代理->redis cluster，一定规模后基本都采用这种方式。
方案3 自己独立开发redis智能客户端
主要实现redis slots管理，failover，一致性hash功能。
标签：定向 控制 透明 维护 failover open 扩展性 探讨 基本
原文地址：https://www.cnblogs.com/nizuimeiabc1/p/9414207.html
