优酷土豆的Redis服务平台化之路.docx

1 Redis 架构的方案经历阶段 . 客户端分片客户端分片: 优点不依赖于第三方中间件,实现方法和代码自己掌控,可随时调整这种分片机制的性能比代理式更好(少了一个中间分发环节) 可控的分发请求,分发压力落在客户端,无服务器压力增加缺点不能平滑的水平扩展节点,扩容/缩容时,必须手动调整分片程序出现故障,不能自动转移,运维性很差客户端得自己维护一套路由算法升级复杂 . Twemproxy Twemproxy : 优点运维成本低。业务方不用关心后端 Redis 实例,跟操作 Redis 一样 Proxy 的逻辑和存储的逻辑是隔离的缺点代理层多了一次转发,性能有所损耗进行扩容/缩容时候,部分数据可能会失效,需要手动进行迁移,对运维要求较高,而且难以做到平滑的扩缩容出现故障,不能自动转移,运维性很差升级复杂 . Redis Cluster Redis Cluster : 优点无中心节点数据按照 Slot 存储分布在多个 Redis 实例上平滑的进行扩容/缩容节点自动故障转移(节点之间通过 Gossip 协议交换状态信息,进行投票机制完成 Slave 到 Master 角色的提升)降低运维成本,提高了系统的可扩展性和高可用性缺点严重依赖外部 Redis-Trib 缺乏监控管理需要依赖 Smart Client( 连接维护,缓存路由表, MultiOp 和 Pipeline 支持) Failover 节点的检测过慢,不如“中心节点 ZooKeeper ”及时 Gossip 消息的开销无法根据统计区分冷热数据 Slave “冷备”,不能缓解读压力 . Proxy+Redis Cluster Smart Client vs Proxy : 优点 Smart Client : ,减少了一层网络传输的消耗,效率较高。 ,实现方法和代码自己掌控,可随时调整。 Proxy : HTTP Restful 接口,隔离底层存储。对客户端完全透明,跨语言调用。 ,维护 Redis Cluster ,只需要平滑升级 Proxy 。 ,底层存储做冷热异构存储。 , Proxy 可以通过秘钥控制白名单,把一些不合法的请求都过滤掉。并且也可以控制用户请求的超大 Value 进行控制,和过滤。 ,可以屏蔽掉一些危险命令,比如 Keys 、 Save 、 Flush All 等。 ,根据不同用户容量申请进行容量限制。 ,根据不同用户的 Key 加上前缀,来进行资源隔离。 ,对于不同的接口进行埋点监控等信息。缺点 Smart Client : ,影响应用的稳定性,提高开发难度。 b. MultiOp 和 Pipeline 支持有限。 , Smart 客户端对连接到集群中每个结点 Socket 的维护。 Proxy : ,性能有所损耗。 ,而且难以做到平滑的扩缩容。 2为什么选择 Nginx 开发 Proxy Master 多 Work 模式,每个 Work 跟 Redis 一样都是单进程单线程模式, 并且都是基于 Epoll 事件驱动的模式。 采用了异步非阻塞的方式来处理请求,高效的异步框架。 ,有自己的一套内存池管理方式,。将大量小内存的申请聚集到一块, 能够比 Malloc 更快。减少内存碎片,防止内存泄漏。减少内存管理复杂度。 Nginx 的访问速度, Nginx 使用了自己的一套连接池。 。 ,对于 Nginx , Redis 的口碑可称得上两大神器。性能也就不用说了。 3 Proxy+Redis Cluster 介绍 Proxy+Redis Cluster 架构方案介绍 ACL 平台申请集群资源,如果申请成功返回秘钥信息。 ,请求至 LVS 服务器。 3. LVS 根据负载均衡策略将请求转发至 Nginx Proxy 。 4. Nginx Proxy 首先会获取秘钥信息,然后根据秘钥信息去 ACL 服务上获取集群的种子信息。(种子信息是集群内任意几台 IP:PORT 节点) 然后把秘钥信息和对应的集群种子信息缓存起来。并且第一次访问会根据种子 IP:PORT 获取集群 Slot 对应节点的 Mapping 路由信息,进行缓存起来。最后根据 Key 计算 SlotId ,从缓存路由找到节点信息。 K/V 信息发送到对应的 Redis 节点上。