行业案例：知乎2000万QPS的Redis集群架构.pdfVIP

知乎Redis的演进之路：从单机到2000万QPS的挑战

本文来自知乎陈鹏老师的精彩分享，作者是该系统的负责人，文章深入介绍了知乎Redis系统的方方面

面，作为后端程序员值得仔细研究。

背景

知乎作为知名中文知识内容平台，每日处理的访问量巨大，如何更好的承载这样巨大的访问量，同时提

供稳定低时延的服务保证，是知乎技术平台同学需要面对的一大挑战。

知乎存储平台团队基于开源Redis组件打造的Redis平台管理系统，经过不断的研发迭代，目前已经形

成了一整套完整自动化运维服务体系，提供一键部署集群，一键自动扩缩容,Redis超细粒度监控，旁路

流量分析等辅助功能。

目前，Redis在知乎规模如下：

●机器内存总量约70TB，实际使用内存约40TB；

●平均每秒处理约1500万次请求，峰值每秒约2000万次请求；

●每天处理约1万亿余次请求；

●单集群每秒处理最高每秒约400万次请求；

●集群实例与单机实例总共约800个；

●实际运行约16000个Redis实例；

●Redis使用官方3.0.7版本，少部分实例采用4.0.11版本。

Redisat智慧

根据业务的需求，我们将实例区分为单机（Standalone）和集群（Cluster）两种类型，单机实例通常

用于容量与性能要求不高的小型存储，而集群则用来应对对性能和容量要求较高的场景。

单机（Standalone）

对于单机实例，我们采用原生主从（Master-Slave）模式实现高可用，常规模式下对外仅暴露Master

节点。由于使用原生Redis，所以单机实例支持所有Redis指令。

对于单机实例，我们使用Redis自带的哨兵（Sentinel）集群对实例进行状态监控与Failover。Sentinel

是Redis自带的高可用组件，将Redis注册到由多个Sentinel组成的Sentinel集群后，Sentinel会对

Redis实例进行健康检查，当Redis发生故障后，Sentinel会通过Gossip协议进行故障检测，确认宕

机后会通过一个简化的Raft协议来提升Slave成为新的Master。

通常情况我们仅使用1个Slave节点进行冷备，如果有读写分离请求，可以建立多个Readonlyslave来

进行读写分离。

如图所示，通过向Sentinel集群注册Master节点实现实例的高可用，当提交Master实例的连接信息

后，Sentinel会主动探测所有的Slave实例并建立连接，定期检查健康状态。客户端通过多种资源发现

策略如简单的DNS发现Master节点，将来有计划迁移到如Consul或etcd等资源发现组件。

当Master节点发生宕机时，Sentinel集群会提升Slave节点为新的Master，同时在自身的pubsub

channel+switch-master广播切换的消息，具体消息格式为：

switch-master

watcher监听到消息后，会去主动更新资源发现策略，将客户端连接指向新的Master节点，完成

Failover，具体Failover切换过程详见Redis官方文档。

RedisSentinelDocumentation[1]

实际使用中需要注意以下几点：

●只读Slave节点可以按照需求设置slave-priority参数为0，防止故障切换时选择了只读节点而不是热

备Slave节点；

●Sentinel进行故障切换后会执行CONFIGREWRITE命令将SLAVEOF配置落地，如果Redis配置中禁

用