Grab Redesigns Counter Service Storage for 50% Lower P99 Latency

TL;DR · AI 摘要
Grab Redesigns Counter Service Storage for 50% Lower P99 Latency - InfoQ InfoQ Homepage News Grab Redesigns Counter Serv...
核心要点
- 主题聚焦:Grab Redesigns Counter Service Storage for 50% L
- 来源:InfoQ,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
Grab 重构计数器服务存储架构,使 P99 延迟降低 50% - InfoQ
InfoQ 首页 News Grab 重构计数器服务存储架构,使 P99 延迟降低 50%
架构与设计
QCon AI 波士顿(2027 年 7 月 8-9 日):AI 原型已经成功。生产环境会发生什么?
Grab 重构计数器服务存储架构,使 P99 延迟降低 50%
2026 年 10 月 7 日 2 分钟阅读
作者:
- Leela Kumili
#### 关注我们
YouTube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 点赞
Bluesky
收听本文 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
Grab 将计数器服务的存储后端从宽列数据库迁移至 Aerospike,重构了数据模型,并引入分阶段流量迁移以避免停机。该服务支持 Grab 的反欺诈平台,每秒处理数万个查询,每天处理约十亿次请求。Grab 报告称生产环境的 P99 读取延迟降低了约 50%,磁盘数据量从约 3TB 减少至 1TB,每节点成本降低了 45% 至 50%。
计数器服务处理时间窗口查询,如最近的乘车请求或失败的支付尝试。其原始设计将 15 分钟、小时和每日计数存储为独立行。每个传入事件触发三次并行读取、内存递增和批量写入,导致四次网络往返。现有的宽列模型使用聚类列高效检索时间范围内的行,该模式由 Apache Cassandra 文档记录。
Grab 没有直接替换存储实现,而是首先将存储访问与 Rust 服务的业务逻辑分离。存储外观暴露了遗留、Aerospike 和模拟实现,配置控制单后端、影子和分流模式。影子读取逐渐从 5% 增加到 20%、50% 和 100%,在将实时流量切换到 Aerospike 之前,通过现有指标测量一致性。
Grab 的工程负责人 Daniel Lim 在 LinkedIn 上描述该方法为:
结合双读写路径进行流量影子和数据一致性验证,并逐步迁移流量。
Grab 的计数器服务迁移架构(来源:Grab 博客文章)
更大的架构变化是数据模型。Grab 最初评估了为每个时间桶保留一行,但 Aerospike 每条记录维护约 64 字节的主索引元数据。在服务所需的记录数量下,这种开销使记录基数成为重要的容量考量因素。
Grab 而是将所有计数器和粒度的时间桶合并到一个包含时间排序映射的单条记录中。写入使用 Aerospike 的原子映射递增操作,而过时条目会被显式删除。Grab 表示,这种重构使记录数量减少了超过一个数量级,并有助于降低索引和磁盘占用。
读取路径也发生了变化。原来的后端在服务器端按时间范围过滤后返回分页行,而 Aerospike 返回包含映射的记录,Grab 在客户端进行过滤。其批量 API 将多个记录操作分组为对数据库节点的请求,减少了服务多键访问模式的网络请求数量。Aerospike 文档指出,批量处理可以将多个记录命令合并为对每个相关节点的请求。
在部署过程中,Grab 还遇到了 Aerospike Rust 客户端的一些问题,包括其最初同步 API 和集群替换期间的 DNS 处理。团队随后采用了异步客户端,并与上游维护人员合作解决 DNS 问题,之后继续部署。
Grab 报告称,迁移过程没有出现停机或数据完整性问题。最终的架构结合了存储抽象、影子验证、逐步流量切换,以及围绕 Aerospike 记录和批量访问特性的数据模型设计。
作者部分的主要包装器
关于作者
部分标题
每个作者的主要包装器
#### Leela Kumili
显示更多
显示更少
#### 此内容属于列式数据库主题
##### 相关主题:
- 开发
- 架构与设计
- 验证
- 宽列数据库
- Cassandra
- 架构
- NoSQL
- Rust
- 领域建模
- 迁移
- 数据库
- 列式数据库
- 映射
- 分布式系统
- 存储
- 数据
- 低延迟
- 相关编辑
- 相关赞助商 AI 的物理约束:AI 如何重塑数据中心
- 相关赞助商 PostgreSQL 为时间序列规模而生 在不牺牲性能的情况下,使用 PostgreSQL 处理海量时间序列数据。了解 Tiger Data 如何实现高速数据摄入、快速查询和可扩展存储。了解更多。
InfoQ 新闻通讯
每周内容精选,每 Tuesday 发送。加入超过 250,000 名高级开发者的社区。查看示例
我们保护您的隐私。