Figma 自研了 Redis 代理，实现六个 9 可用性

作者 | Matt Saunders

译者 | 张卫滨

Figma 发布了其自研 Redis 代理服务 FigCache 的详细实践，替换了此前分散且已成为站点可用性风险的缓存栈。该系统由软件工程师 Kevin Lin 在 一篇文章中进行了介绍，自 2025 年下半年上线生产环境以来，已经在其缓存层实现了公司所称的六个 9 可用性。

我们的 Redis 平台在可扩展性和可靠性上的不足，正在日益威胁 Figma 站点的可用性。 Kevin Lin，Figma 软件工程师

这是 Figma 在短时间内进行的第二次重大存储架构的重构。2024 年，公司 完成了一个为期九个月的项目，将 Postgres 栈做了水平分片，并构建了名为 DBProxy 的定制代理服务，用于在物理分片之间拦截、解析和路由 SQL 查询。FigCache 把这一模式扩展到临时数据层，延续了同一个理念：通过代理层吸收运维复杂性，让应用代码不必承担这些负担。

关于推动该项目的现有“症状”，相信对于任何大规模运维 Redis 的人都并不陌生。连接量逐步逼近硬性上限。客户端服务快速扩容会引发新连接请求的“惊群效应（thundering herd）”，导致 Redis I/O 饱和并拖累可用性。随着时间推移，团队还积累了大量彼此独立的客户端库，每个库都有自己的可观测性行为，使故障快速诊断变得非常困难。Lin 写道，团队最初构建了按服务定制的权宜方案，包括自定义客户端连接池层，但最终认为这些方案只是“把 Redis 故障与顶层站点可用性隔离开”，而没有解决底层的结构性问题。

选择自研而不是采用现有开源代理的根本原因在于可用方案的能力边界。Lin 指出，现有方案通常只提供“基础的 RPC 服务，无法从任意入站 Redis 命令中提取完整且带注释的参数”。缺少这种语义感知能力，Figma 既无法实现所需的运行时护栏，也无法定义可由代理本身拦截并处理的自定义命令。公司还必须兼容割裂的现有客户端生态：有的服务支持 Redis Cluster，有的使用 TLS，也有的两者都不支持。自有层让团队可以构建兼容垫片（shim），透明处理所有变体，其中包括一种 Redis Cluster 的仿真模式，把代理伪装成集群提供给支持集群的客户端。

在现有开源 Redis 代理上扩展定制业务逻辑，实践中既笨重又在协作流程上非常脆弱，还需要维护一个很难与上游保持同步的源码分支。 Kevin Lin，Figma 软件工程师

FigCache 本身是一个无状态服务，构建在 ResPC 之上。ResPC 是团队使用 Go 编写的库，用于在 Redis Serialization Protocol(RESP) 之上提供 RPC 框架。该代理位于客户端应用与 AWS ElastiCache 上的 Redis 集群群组之间。其架构将前端层与后端层进行了分离：前端层负责连接管理与协议感知的命令解析，后端层负责连接复用以及面向上游集群的命令执行。正是这种分离让系统具备可扩展性：任一层都可引入新行为而不干扰另一层。

FigCache 较为特别的设计之一是其后端配置方式。它不使用静态配置文件，而是把决定命令路由与处理方式的引擎树表达为 Starlark 程序，在虚拟机中运行时求值，再生成服务器消费的 Protobuf 结构化配置。这意味着运维人员可以仅通过配置来修改路由逻辑、基于键前缀的拒绝规则以及命令类型拆分，而无需重新部署服务器的二进制程序。

该代理还处理了一类 Redis Cluster 通常会直接报错给客户端的问题。当 pipeline 或事务跨越多个哈希槽（hash slot）时，Redis Cluster 会返回 CROSSSLOT 错误，因为这些操作可能触及不同物理分片。FigCache 包含一个扇出过滤引擎，它可以拦截符合条件的多分片 pipeline，并在内部以并行 scatter-gather 方式执行：分发单条命令、聚合响应，再返回给客户端。从应用视角看，这类错误不会出现。

与代理配套的还有 Go、Ruby 和 TypeScript 的一方（first-party）客户端库。这些库是对 Figma 代码库中已在使用的开源客户端的封装，使团队避免了从零构建私有协议。将服务迁移到 FigCache 在最简单场景下只需一行配置变更来更新端点即可。

迁移策略被设计为每个阶段都可回退。流量按服务逐步切换，借助特性开关，可以在不改代码、不部署二进制程序的情况下即时回滚。对于 Figma 主 API 服务等大工作负载，流量是在独立域之间渐进式迁移的，而非一次性切换。每次线上发布前，团队都会执行广泛的压测，包括每周一次在生产环境进行的分布式压力测试，把吞吐量推到常规自然峰值的一个数量级以上。

这一思路在行业中也有相似案例。lastminute.com 的工程师在 2024 年 重构了搜索聚合系统，使用 Redis 作为中间结果存储，并通过 RabbitMQ 将供应商搜索驱动与聚合服务解耦。他们的目标类似，也就是降低耦合、提升可扩展性、隔离组件间故障传播。Figma 的做法更进一步，它不仅重构数据流，还把 Redis 访问层本身进行了集中化。

更广泛的 Redis 生态在近年也发生了一些变化。2025 年 5 月，在 2024 年 3 月改用更严格的 SSPLv1 协议并引发争议的一年后，Redis回归 AGPLv3 开源许可。这一变化也促成了 Valkey 分叉。伴随许可调整发布的 Redis 8.0 包含性能提升，项目方称命令速度最高可提升 87%，吞吐量最高可达 2 倍。在这一背景下，Figma 构建可替换后端存储系统的抽象层显得很慎重：Lin 提到，FigCache 被设计为在同一基于 RESP 的接口后支持包括 AWS MemoryDB 和 Figma 自有 Postgres 栈在内的替代后端。

这类基础设施究竟要“自研还是采购”，这是很多工程团队都会面对的问题。Sneha Wasankar 在 dev.to 关于生产环境 Redis 缓存策略的文章 中指出，cache-aside、write-through 或 write-behind 模式的选择，往往不如底层基础设施本身的可靠性重要。Figma 这篇文章的核心论点之一就是，当规模足够大时，基础设施本身就会成为产品。

FigCache 消除了曾经导致多次高严重级别事故的“惊群”连接失败。分片故障切换、集群扩缩容、硬件轮换和 OS 升级如今都成为零停机的后台操作。团队会在全部 Redis 覆盖范围内频繁执行故障切换，作为系统韧性的常态化演练。整个缓存栈的可观测性也已统一，指标、日志和追踪为工程师提供了跨全部工作负载的一致视图，涵盖延迟、吞吐、负载大小和命令基数。Lin 表示，故障诊断时间已从数小时或数天缩短到数分钟。

查看英文原文：

Figma Builds In-House Redis Proxy to Hit Six Nines Uptime（https://www.infoq.com/news/2026/05/figma-redis-figcache/）

声明：本文由 InfoQ 翻译，未经许可禁止转载。