Uber如何使用集成的Redis缓存支持每秒4000万次读取？
内容提要
QA Wolf是一种QA解决方案，可在几周内将Web应用程序的测试覆盖率提高到80%。Uber开发了名为Docstore的分布式数据库，用于构建其服务。Uber创建了一个集成的缓存解决方案CacheFront，以解决低延迟数据库读取的挑战。CacheFront通过将缓存与数据库解耦，使用缓存失效和数据更改捕获来提供高性能和一致性。CacheFront的设计目标是减少扩展需求，提高读取请求的延迟和稳定性，并降低数据库引擎层的资源分配。CacheFront确保了99.99%的一致性，具备可扩展性和容错性。CacheFront目前在生产环境中支持超过40M的请求每秒。
延伸解读
CacheFront 如何解决缓存管理碎片化问题
Uber 内部各团队原本自行管理 Redis 缓存集群，导致缓存失效逻辑重复、维护成本高，且难以保证一致性。CacheFront 将缓存层集成到 Docstore 查询引擎中，由 Docstore 团队统一负责 Redis 的维护和支持，使缓存对服务透明。这样，业务团队只需关注业务逻辑，无需再为缓存分心，从而减少了重复建设和潜在的不一致风险。
CDC 缓存失效与写去重机制
CacheFront 利用 Docstore 的变更数据捕获服务 Flux 订阅 MySQL binlog 事件，在数据变更后几秒内失效或更新 Redis 中的对应行，避免了 TTL 策略下可能长达分钟的延迟。由于读写路径可能同时写入缓存，他们基于 MySQL 行时间戳作为版本号，通过 Redis EVAL 命令去重，防止旧数据覆盖新值，从而在最终一致性基础上提升了数据准确性。
跨区域缓存预热与分片策略
在多区域 active-active 部署中，CacheFront 通过跨区域 Redis 复制键而非值，并在远端区域触发查询引擎按需回源数据库并写入缓存，确保缓存始终温暖，避免故障转移时缓存击穿。同时，为应对大客户的高请求量，单个 Docstore 实例可映射多个 Redis 集群，且 Redis 分片方案与数据库分片不同，防止单个 Redis 集群故障导致数据库热分片。
性能提升与成本效益
CacheFront 上线后，P75 延迟降低 75%，P99.9 延迟降低超过 67%，并抑制了延迟尖峰。缓存一致性达到 99.99%。在某个每秒 600 万读的用例中，缓存命中率 99%，故障转移成功。成本方面，原本需要约 6 万 CPU 核的存储引擎，现在仅需 3 千 Redis 核即可支撑相同负载。目前 CacheFront 生产环境支持超过每秒 4000 万次请求。
Q&A
Uber的CacheFront解决了什么问题？
CacheFront解决了低延迟数据库读取的挑战，减少了扩展需求，提高了读取请求的稳定性，并降低了数据库资源分配。
CacheFront如何确保缓存与数据库的一致性？
CacheFront使用Flux进行缓存失效，确保缓存与数据库在几秒内保持一致，并通过比较缓存和数据库的数据来验证一致性。
CacheFront的实施对Uber的性能有什么影响？
CacheFront的实施显著降低了延迟，P75延迟下降了75%，P99.9延迟下降了67%，并支持超过4000万的请求每秒。
CacheFront是如何处理缓存失效的？
CacheFront通过配置TTL和使用Flux的变更数据捕获来处理缓存失效，确保在数据库更改后快速更新缓存。
CacheFront如何支持高请求量的客户？
CacheFront支持多个Redis集群以应对大客户的高请求量，并通过分片避免数据库的热分区问题。
CacheFront的设计目标有哪些？
CacheFront的设计目标包括减少扩展需求、提高延迟稳定性、降低数据库资源分配，并使缓存管理透明化。
