Canva 对其会话撤销基础设施进行了重新设计，旨在支持数亿个活跃会话，同时在处理大多数身份验证请求时避免进行联网数据库查询。新架构将撤销数据以紧凑、不可变的形式存储在 Amazon S3 中，并将其作为内存索引分发到应用程序网关。Canva 表示，这种方法提高了部署速度，减少了数据库基础设施的开销，并将撤销缓存的内存占用降低了 87.5%。
Canva 将会话信息存储在加密的浏览器 Cookie 中，使网关无需连接网络数据存储即可对请求进行身份验证。不过，已撤销会话和权限变更需要近乎实时地反映出来。此前，Canva 将 12 小时的撤销数据保存在内存中，而会话刷新操作仍然需要持续查询 MySQL。随着平台规模的扩大，在部署过程中，可能有数百个网关实例各自向 MySQL 请求超过 100 万条撤销记录，从而引发了集中的数据库负载压力。
Canva 选择了 Amazon S3 而非 Redis，旨在避免再额外维护另一个数据存储系统，同时为撤销数据提供持久化存储。12 小时的撤销窗口被划分到 30 分钟的 S3 对象，网关会根据需要下载这些对象。每次撤销都以一个 16 字节的二进制记录表示，其中包含主体和时间戳。排序数组支持直接内存搜索，从而将缓存占用空间减少了 87.5%。网关使用有条件的 GET 请求下载已更改的块，并丢弃超过 12 小时的数据。异步工作进程会扫描新的撤销记录，将其合并到最新的块中，并上传结果。当工作进程更新同一对象时，有条件的 PUT 请求提供了乐观并发控制；而 ZooKeeper 领导者选举机制虽然能减少冲突，但并非确保正确性的必要条件。
软件工程师亚 Adam Urban 在 LinkedIn 上分享该文章时强调， Amazon S3 不仅是一个对象存储，更是将不可变对象和条件写入作为协调原语来使用。
Worker 任务如何将撤销操作从数据库复制到 S3（图片来源：Canva 博文）
该设计还考虑了恢复和部署问题。网关可以通过下载相关的 S3 数据块来重建其本地撤销状态，而不需要依赖数据库来重建缓存。Canva 表示，该工作节点每秒可以处理超过 2000 次撤销操作，超出了预期需求；而即使是一个包含 100 万次撤销操作的数据块，其二进制数据大小也仅约为 16 兆字节。
该架构在 Reddit 上引发了讨论，有评论者建议：
只需采用刷新令牌方案，将访问令牌的有效期设得短一点，并将刷新令牌存储在数据库中即可，不需要将每个会话与 100 万条缓存的撤销记录逐一比对。
Canva 工程师 Llew Vallis 在 Reddit 的一场讨论中回应道：
将撤销数据保存在内存中能实现更好的权衡，因为频繁的令牌刷新会增加数据库负载，并在刷新操作期间导致系统可用性受限于数据库。
迁移完成后，Canva 将其会话撤销数据库缩减至两个读取冗余副本，并提升了部署速度。数据库负载也变得更加可预测，可以根据撤销写入吞吐量和网站整体流量进行扩展，而非加载缓存的网关实例数量。Canva 表示，他们在真实基础设施上测试了多种实现方案，这帮助他们验证了所选的设计能否满足其可扩展性要求，包括单个数组中涉及数十万次撤销的工作负载。
原文链接：https://www.infoq.com/news/2026/08/canva-session-revocation-scale/
