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

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