Grab将CounterService迁移至Aerospike，P99延迟降50%，磁盘占用减至1/3

Grab 完成了一项关键基础设施升级：其 Counter Service 的存储后端已全面迁移至 Aerospike。该服务日均处理约 10 亿次请求，为 Grab 的反欺诈系统提供实时计数支持，例如统计用户近期叫车频次、支付失败次数等时间窗口指标。此次迁移不仅显著提升了性能与成本效率，更在无停机前提下保障了数据一致性，成为高可用系统演进的典型案例。

Counter Service 的核心功能是响应基于时间粒度（15 分钟、每小时、每日）的聚合查询。原有架构采用宽列数据库（类似 Apache Cassandra 的设计），将不同时间粒度的计数分别存为独立行。每次事件触发时，需执行三次并行读取、一次内存递增与一次批量写入，共四次网络往返，效率受限于 I/O 路径冗余。

迁移并非简单替换存储引擎，而是一次系统性重构。Grab 工程团队首先将存储访问逻辑与业务层解耦，构建了一个统一的存储门面（Storage Facade），支持旧存储、Aerospike 及模拟实现三种后端，并通过配置动态切换模式：单后端、影子读（Shadow Read）、流量拆分。影子读比例从 5% 逐步提升至 20%、50%，最终达 100%，期间持续比对两套系统的输出结果，确保数据一致性达标后再切流。

如图所示，旧路径依赖服务器端分页与范围过滤，需多次并发扇出；新路径则利用 Aerospike 的批处理 API 与原子映射操作，在客户端完成时间戳筛选与聚合。具体而言，Grab 放弃了“每时间桶一行”的朴素方案——因 Aerospike 每条记录需约 64 字节主索引元数据，按原设计将产生巨大开销。最终方案是将同一计数器在某一时间粒度下的所有时间桶整合为单条记录，内部以时间戳排序的映射（Map）结构存储。写入时调用 Aerospike 的 map.increment 原子操作，并显式清理过期条目；读取时一次性拉取整条记录，再由客户端按需过滤。

这一数据模型重构使记录总数减少一个数量级以上，直接降低了索引内存占用与磁盘空间消耗。生产数据显示，磁盘数据量从约 3 TB 压缩至 1 TB，降幅达 66%；单节点硬件成本随之下降 45% 至 50%。更重要的是，P99 读取延迟降低约 50%，满足了反欺诈场景对低延迟的严苛要求。

迁移过程亦暴露了技术细节挑战。初期团队使用 Aerospike 的 Rust 同步客户端，在集群滚动更新期间遭遇 DNS 解析异常，导致部分请求失败。后续改用异步客户端，并协同上游维护者修复 DNS 缓存机制，才完成稳定发布。Grab 强调，整个过程未引发服务中断或数据损坏，验证了其“双重验证+渐进切换”策略的有效性。

值得注意的是，该案例反映出现代互联网企业对存储层精细化治理的趋势。随着业务规模扩大，单纯依赖通用数据库已难以兼顾性能、成本与运维复杂度。Aerospike 作为专为高性能、低延迟设计的 NoSQL 数据库，在键值与混合负载场景中展现出优势：其批处理能力有效缓解多键访问的网络开销；原子映射操作避免了传统 CAS（Compare-And-Set）在高并发下的重试风暴；而内存优先架构则天然适配计数类服务的热数据特征。

对比行业同类实践，华夏银行曾采用曙光存储将小文件检索提速 5–10 倍，但属对象存储场景；而 Grab 的案例聚焦于事务性更强、延迟更敏感的实时计数服务，技术路径更具参考价值。尤其在东南亚出行与支付生态中，反欺诈系统需在毫秒级响应海量并发事件，任何延迟抖动都可能影响风控决策质量。此次迁移后，Counter Service 的稳定性与扩展性获得实质性提升，为后续接入更多实时风控策略打下基础。

从工程方法论看，Grab 的做法体现了成熟平台团队的典型思维：不追求一步到位，而是通过抽象层隔离变化、用影子模式验证假设、以数据驱动决策。这种“可观察、可回滚、可验证”的迁移范式，正逐渐成为云原生时代数据库升级的标准流程。

目前，该服务已稳定运行于生产环境，支撑 Grab 全平台的实时风险识别。未来，团队计划将类似模式推广至其他高频计数场景，进一步释放存储层的性能潜力。