孤本网
/ 0 阅读
0
0

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

一句话结论

Grab 将 Counter Service 存储后端迁至 Aerospike 并重构数据模型,实现 P99 读取延迟降低约 50%,磁盘占用从 3TB 降至 1TB,单节点成本下降 45% 至 50%。

关键要点

  • 日均 10 亿次请求的反欺诈服务完成存储迁移,全程无停机且无数据完整性事故。
  • 数据模型从 15 分钟、每小时、每日三行独立存储重构为单记录时间戳映射,记录数量减少 10 倍以上的量级。
  • 采用影子读流量从 5% 阶梯式升至 100% 的验证机制,确保新旧存储数据一致性后再切换主流量。
  • 利用 Aerospike 原子映射递增操作替代原有四次网络往返,客户端筛选逻辑替代服务端分页筛选。
  • 迁移过程中解决 Rust 客户端同步 API 限制及集群替换期间的 DNS 处理缺陷。

背景与事实

Grab 的 Counter Service 是其反欺诈平台的核心组件,承担高频时间窗口计数任务,例如统计近期叫车请求或支付失败记录。该服务运行在 Apache Cassandra 宽列数据库上,每秒处理数万次查询,日均请求量约 10 亿次。原有架构针对时间窗口查询进行了特殊优化,将 15 分钟、每小时和每日的计数分别存储为独立的行。这种设计基于 Apache Cassandra 文档推荐的聚簇列模式,能够高效检索特定时间范围内的数据行。然而,每个传入事件都需要触发三次并行读取、一次内存内递增操作以及一次批量写入,累计产生四次网络往返。这种高延迟的交互模式在请求量持续增长时成为性能瓶颈。

Grab 工程团队决定将该服务的存储后端迁移至 Aerospike,并同步重构数据模型。迁移前团队评估过为每个时间桶保留独立行的方案,但发现 Aerospike 会为每条记录维护约 64 字节的主索引元数据。按照该服务所需的记录数量,这一固定开销使记录基数成为容量规划的关键限制因素。Grab 最终采用整合方案,将一个计数器和一种时间粒度下的所有时间桶打包进单条记录,内部包含按时间戳排序的映射结构。写入路径使用 Aerospike 的原子映射递增操作,同时显式删除过期条目。这项重构使记录数量减少了一个数量级以上,直接降低了索引维护成本和磁盘占用。

读取路径架构也随之调整。原有后端返回由服务器按时间范围筛选的分页数据行,而新架构中 Aerospike 返回包含完整映射的记录,由 Grab 服务在客户端进行筛选。为降低多键访问模式下的网络开销,Grab 采用 Aerospike 批处理 API 将多条记录操作组合为发送至数据库节点的单一请求。Aerospike 官方文档指出,批处理机制可将多条记录命令合并为对每个相关节点的一次网络请求。在存储访问层面,Grab 将存储访问逻辑与 Rust 服务业务逻辑分离,实现存储门面层,支持旧存储、Aerospike 和模拟实现三种后端。配置控制可切换单后端、影子读和流量拆分模式。

迁移过程采用分阶段策略。影子读取比例从 5% 起步,逐步提升至 20%、50% 直至 100%,每个阶段通过现有指标体系衡量数据一致性。验证通过后才将真实流量转移至 Aerospike。Grab 工程负责人 Daniel Lim 在 LinkedIn 上将此方法描述为“将用于流量影子验证和数据一致性验证的双重读写路径,与渐进式流量迁移结合起来”。发布期间团队遇到 Aerospike Rust 客户端的同步 API 限制及集群替换期间的 DNS 处理问题,随后采用异步客户端并与上游维护者合作修复 DNS 缺陷后继续推进。

影响分析

本次迁移案例为中文开发者提供了大型系统中存储替换的标准操作流程参考。双重读影子验证与渐进式流量切换的组合策略,可在不中断生产服务的前提下完成存储引擎替换,该模式适用于任何需要替换关键路径存储系统的团队。将服务端筛选逻辑下放至客户端以适配新存储引擎特性,结合批处理 API 优化网络请求,展示了跨层架构调整对性能优化的直接作用。对使用 Rust 开发高并发服务的团队,该案例提醒应优先选择异步客户端并提前验证 DNS 处理逻辑,避免在发布环节受阻。记录数减少 10 倍以上的数据结构优化经验,说明存储引擎迁移需同步重新评估数据模型,单纯替换引擎而不调整数据结构可能无法充分释放新引擎的性能优势。

适用边界

该迁移方案的成功依赖于服务具备支持影子读和流量拆分的架构抽象层,且数据访问模式以时间窗口计数为主、可容忍客户端筛选延迟。对于强一致性事务处理场景、需服务端复杂查询的 OLTP 系统、或对单记录体积有严格限制的数据密集型应用,此方案的不适用条件较为明显。同时,依赖批处理优化网络请求的策略要求客户端具备组合操作能力,纯单条写读场景下该优化效果有限。

孤本观察

作为编辑判断,本次迁移的核心价值在于将存储引擎替换从简单的组件换购转变为“数据模型重设计加流量验证机制加客户端逻辑重构”的三合一工程,其可复制性远高于单纯的存储替换项目。

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

Grab 反欺诈核心计数器迁移 Aerospike,P99 延迟降 50% 磁盘降 3TB 至 1TB

常见问题

Grab 迁移至 Aerospike 后,磁盘占用具体下降了多少?

磁盘占用从 3TB 降至 1TB,单节点成本下降 45% 至 50%。

迁移过程中采用了何种流量验证策略以确保数据一致性?

采用影子读流量从 5% 阶梯式升至 100% 的验证机制,确认一致性后切换主流量。

重构数据模型后,记录数量发生了怎样的变化?

记录数量减少 10 倍以上的量级,从多行独立存储变为单记录时间戳映射。

为什么 Grab 选择将服务端筛选逻辑迁移至客户端?

为了适配 Aerospike 返回完整映射的特性,并降低多键访问模式下的网络开销。

该迁移方案不适用于哪些场景?

不适用于强一致性事务处理、需服务端复杂查询的 OLTP 系统及对单记录体积有严格限制的应用。

来源:InfoQ 中文 AI


评论