Figma自研Redis代理：六个9可用性背后的架构抉择

八年前，Redis还是大多数团队眼中的"简单缓存"。今天，它已经成为支撑十亿级日活产品的核心基础设施——而当它出问题时，整个站点跟着宕机。Figma最近公开了他们的解法：一套完全自研的Redis代理服务FigCache，把缓存层的可用性推到了六个9。

这不是Figma第一次对存储层动刀。2024年，他们刚花九个月把Postgres做了水平分片，自建了DBProxy来路由SQL查询。FigCache是同一思路的延伸：用代理层吃掉运维复杂度，让业务代码保持干净。软件工程师Kevin Lin在官方博客中写道："我们的Redis平台在可扩展性和可靠性上的不足，正在日益威胁Figma站点的可用性。"

推动这个项目的症状，运维过大规模Redis的人应该都熟悉。连接数逼近硬性上限；服务扩容时的新连接请求引发"惊群效应"，直接打爆Redis I/O；十几个独立的客户端库各自为政，故障排查像猜谜。Figma团队最初做了些权宜之计——自定义连接池、按服务定制的隔离层——但Lin坦承这些只是"把Redis故障与顶层站点可用性隔离开"，没碰底层结构。

为什么不用开源代理？Lin的解释很直接：现有方案只提供"基础的RPC服务，无法从任意入站Redis命令中提取完整且带注释的参数"。没有语义感知，就做不到运行时护栏，也定义不了代理层能拦截处理的自定义命令。更麻烦的是Figma的客户端生态已经割裂：有的支持Redis Cluster，有的用TLS，有的两者都不支持。自研代理可以透明兼容所有变体，包括一种"伪装模式"——让支持集群的客户端以为自己在跟集群对话，实际背后是个单点代理。

FigCache本身是无状态服务，底层是团队用Go写的ResPC库，在RESP协议之上提供RPC框架。架构上分前后端两层：前端管连接和协议解析，后端管连接复用和上游执行。这种分离让扩展变得干净——加新行为不需要两边一起改。比较特别的是后端配置：不用静态文件，而是用Starlark程序在运行时求值，生成Protobuf配置。运维改路由规则、键前缀拒绝策略、命令拆分逻辑，都不需要重新部署二进制。

代理还解决了一个Redis Cluster的硬约束。当pipeline或事务跨越多个哈希槽时，集群会直接抛CROSSSLOT错误。FigCache的扇出过滤引擎会拦截这类请求，内部做并行scatter-gather：分发、聚合、返回，应用端无感知。配套还有Go、Ruby、TypeScript的一方客户端库，封装自现有开源客户端——迁移最简单的情况只需改一行端点配置。

整个上线过程被设计成每个阶段都可回退。流量按服务逐步切，特性开关支持即时回滚，无需代码变更或重新部署。对大工作负载如主API服务，流量是在独立域之间渐进迁移，而非一次性切换。每次发布前都做压测，包括每周一次生产环境的分布式压力测试，吞吐量推到日常峰值的一个数量级以上。

同类思路在行业里已有先例。2024年lastminute.com重构搜索聚合系统时，用Redis存中间结果，通过RabbitMQ解耦供应商搜索与聚合服务——目标也是降低耦合、隔离故障。Figma走得更远：不仅重构数据流，还把Redis访问层本身集中化。

这个时机也值得关注。2025年5月，Redis在改用SSPLv1协议引发争议一年后，回归AGPLv3开源许可，同期发布的Redis 8.0宣称命令速度最高提升87%、吞吐量翻倍。这也催生了Valkey分叉。Figma的抽象层设计显得颇为审慎：Lin提到FigCache被设计为可对接替代后端，包括AWS MemoryDB和Figma自有的Postgres栈，只要它们支持RESP协议。

"自研还是采购"是工程团队的经典困境。Dev.to上关于生产环境Redis策略的讨论指出，cache-aside、write-through或write-behind模式的选择，往往不如底层基础设施的可靠性关键。Figma这篇文章的核心论点之一是：当规模足够大时，基础设施本身就会成为产品。

FigCache上线后的数据验证了这一点。"惊群"连接失败——曾经导致多次高严重级别事故的元凶——被消除。分片故障切换、集群扩缩容、硬件轮换、OS升级全部变成零停机的后台操作。团队现在会在全部Redis覆盖范围内频繁执行故障切换，作为韧性演练。可观测性也被统一：指标、日志、追踪给工程师一致的跨工作负载视图，覆盖延迟、吞吐、负载大小和命令基数。Lin表示，故障诊断时间从数小时或数天缩短到数分钟。

六个9的可用性，换算下来年停机时间不到32秒。这个数字背后不是某个银弹技术，而是一整套关于"谁来承担复杂度"的架构决策——以及承认当开源方案的能力边界撞上业务规模时，有时候最务实的选择是亲手重写那一层。