新浪Redis运维实践

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/ningyu1

摘要

文档介绍了新浪Redis运维实践，涵盖平台规模（1000亿+ hits/天、15个IDC数据中心、1200+物理机器、7000+实例）和重要业务。核心内容包括精细化运维，分为基础服务（服务高可用、监控报警、服务化）和细化服务（成本优化、数据支撑）。成本优化部分通过表格展示了Redis低读写量比例端口、无读写端口（连续一周）和低内存利用率端口的实例数据，如端口7896的读写比达5541.4585，端口8193内存使用6M等。部署架构包括Redis单机、Redis Cluster和Redis Tribe。Redis集群演化经历了Redis Tribe、类Codis产品、Redis Cluster到Redis Cluster + Proxy阶段，Proxy支持动态伸缩、跨南北部署、无需客户端支持smart client及本地化读从库。

AI总结

新浪Redis运维实践主要围绕平台概况、精细化运维和Redis Cluster Proxy三部分展开。

**平台规模**：每日处理超过1000亿次请求，覆盖15个IDC数据中心，运行在1200多台物理机器上，管理7000多个实例。

**精细化运维**：分为基础服务和细化服务。基础服务包括服务高可用、监控报警和服务化。细化服务重点在于成本优化和数据支撑。成本优化通过识别并处理低效资源实现，具体案例包括：
- **低读写量端口**：例如，端口7896和7906的读写比超过5000，属于写多读少，用于“猜你喜欢”等业务；端口22803读写比约3267，用于媒体平台Push系统。
- **无读写端口（连续一周）**：如端口8193（直播聊天室，内存6M）、8067（体育竞猜，5M）、8068（舆情监控，5M），这些端口完全没有流量。
- **低内存利用率端口**：例如，端口22126（直播平台）仅使用2M内存，但分配了19072M，利用率仅0.01%；端口22128（战斧项目）使用9M，分配57220M；端口7991（媒体缓存）使用20M，分配95364M。

**Redis Cluster Proxy**：介绍了平台Redis集群的演化过程。最初使用Redis Tribe，但需要前后端部署且无人维护。随后尝试类Codis产品和原生Redis Cluster，但存在客户端不友好、无法读取从库、无法跨异地IDC部署等问题。最终采用**Redis Cluster + Proxy**方案，该方案支持动态伸缩、跨南北部署，客户端无需支持smart client，且支持本地化读取从库。