InfoQ

Canva Shares S3 Based Architecture for Session Revocation Across Hundreds of Millions of Sessions

8.5内容质量
Canva Shares S3 Based Architecture for Session Revocation Across Hundreds of Millions of Sessions

TL;DR · AI 摘要

Canva通过基于S3的架构优化,实现大规模会话撤销,内存占用减少87.5%。

核心要点

  • 使用S3存储会话撤销数据,避免数据库查询并减少87.5%内存占用
  • 将12小时撤销窗口拆分为30分钟S3对象,支持按需下载
  • 异步处理实现每秒2000+撤销操作,提升部署效率

结构提纲

按章节快速跳转。

  1. 介绍Canva面临的大规模会话撤销挑战及传统方案的局限性

  2. 基于S3的存储方案替代Redis,实现数据持久化与高可用

  3. 将撤销数据拆分为16字节二进制记录,按30分钟分片存储

  4. 通过排序数组实现内存内快速查找,降低缓存内存占用

  5. 异步工作者每秒处理2000+撤销事件,合并上传至S3

  6. 网关可直接从S3重建本地撤销状态,无需依赖数据库

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 基于S3的会话撤销架构
    • 核心架构
      • S3存储替代Redis
      • 内存索引优化
    • 数据处理
      • 30分钟分片存储
      • 异步处理机制
    • 部署特性
      • 无数据库依赖
      • 条件写入控制

金句 / Highlights

值得收藏与分享的关键句。

#架构设计#S3#会话管理#分布式系统
打开原文

Canva 分享基于 S3 的架构,用于处理数亿会话的撤销 - InfoQ

InfoQ 首页新闻 Canva 分享基于 S3 的架构,用于处理数亿会话的撤销

架构与设计

在线 InfoQ 架构师认证(9 月 14 日):架构的社会技术层面。

Canva 分享基于 S3 的架构,用于处理数亿会话的撤销

2026 年 8 月 10 日 2 分钟阅读

作者:

  • Leela Kumili

#### 关注我们

YouTube

232,000 关注者

LinkedIn

26,000 关注者

Instagram

RSS

19,000 读者

X

57,100 关注者

Facebook

21,000 点赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

点赞

新下拉阅读列表

  • 阅读列表

Canva 重新设计了其会话撤销基础设施,以支持数亿个活跃会话,同时避免大多数认证请求的网络数据库查询。新架构将撤销数据存储在 Amazon S3 中作为紧凑的不可变记录,并将数据以内存索引的形式分发到应用网关。Canva 表示,这种方法提高了部署速度,减少了数据库基础设施,并将撤销缓存的内存占用减少了 87.5%。

Canva 将会话信息存储在加密的浏览器 cookie 中,使网关能够在不联系网络数据存储的情况下验证请求。然而,被撤销的会话和权限变更需要近乎实时地反映。Canva 之前在内存中保存了 12 小时的撤销数据,而会话刷新仍会检查 MySQL。随着平台的增长,数百个网关实例在部署期间每个都可能向 MySQL 请求超过一百万次撤销,造成协调的数据库负载。

Canva 选择 Amazon S3 而非 Redis,以避免运营另一个数据存储,同时为撤销数据提供持久存储。12 小时的撤销窗口被划分为 30 分钟的 S3 对象,网关按需下载这些对象。每个撤销以包含主体和时间戳的 16 字节二进制记录表示。排序数组实现了直接的内存搜索,将缓存占用减少了 87.5%。网关使用条件 GET 下载变更块并丢弃超过 12 小时的数据。异步工作者扫描新撤销,将其合并到最新块中并上传结果。当工作者更新相同对象时,条件 PUT 提供乐观并发控制,而 ZooKeeper 主选举减少冲突但不是正确性所必需的。

在 LinkedIn 上分享文章时,软件工程师 Adam Urban 强调了 Amazon S3 的使用不仅作为对象存储,还指出其不可变对象和条件写入的使用作为协调原语。

工作者任务如何将撤销信息从数据库复制到 S3(来源:Canva 博客文章)

该设计还解决了恢复和部署问题。网关可以通过下载相关 S3 块来重建本地撤销状态,而无需数据库重建缓存。Canva 表示,工作者每秒可处理超过 2000 次撤销,超过预期需求,即使包含一百万次撤销的块也仅代表约 16 兆字节的二进制数据。

该架构在 Reddit 上引发了讨论,其中一位评论者建议

只需使用刷新令牌方案,缩短访问令牌的有效期,并将刷新令牌存储在数据库中,无需针对数百万个缓存的撤销记录检查每个会话。

Canva 工程师 Llew Vallis 回应了 Reddit 上的讨论:

将撤销数据存储在内存中提供了更好的权衡,因为频繁的令牌刷新会增加数据库负载,并使可用性在刷新操作期间依赖于数据库。

迁移后,Canva 将其会话撤销数据库缩减为两个读副本以实现冗余,并提升了部署速度。数据库负载也变得更加可预测,随着撤销写入吞吐量和整体网站流量进行扩展,而非依赖网关实例数量加载缓存。Canva 表示,在真实基础设施上测试多种实现方案,验证了所选设计能够满足其可扩展性需求,包括单个数组中涉及数十万次撤销的工作负载。

main wrapper for authors section

关于作者

section title

main wrapper for each author

#### Leela Kumili

显示更多

显示更少

#### 此内容属于 AWS 主题

##### 相关主题:

  • 开发
  • 架构与设计
  • MySQL
  • S3
  • Redis
  • 云架构
  • 缓存
  • AWS
  • 可扩展性
  • 微服务
  • 不可变基础设施
  • 身份验证
  • 相关编辑内容
  • 相关赞助商
  • 相关赞助商 2026 年 8 月 27 日,东部时间下午 1 点 Below the Framework:为什么代理上下文是一个基础设施问题 演讲者:Boyd Stowe - Tacnode 创始解决方案架构师

InfoQ 新闻通讯

每周内容精选,每周二发送。加入超过 25 万名高级开发者的社区。查看示例

我们保护您的隐私。 /think