解读

国内互联网与金融系统普遍采用事件溯源（Event Sourcing）实现审计、对账、灰度回滚，但事件表按“只追加”原则写入，日均千万级事件，半年即可破百亿行。性能测试阶段常因磁盘 I/O 飙升、索引深度增加、P99 查询耗时从 50 ms 涨到 2 s 而被生产方问责。面试官想确认候选人能否在“容量/成本/合规”三角约束下给出可落地的清理方案，同时不破坏事件溯源的核心价值——“任何时候都能重放溯源”。因此，答题必须兼顾：1) 性能测试视角的量化指标；2) 国内等保、银保监、上交所日志留存年限等合规要求；3) 线上真实可行的技术路线。

知识点

1. 事件溯源四大约束：不可变、顺序性、全量重放、合规留存。
2. 性能测试三板斧：基准→压测→调优，需给出清理前后的 TPS、P99 Latency、磁盘 IOPS、索引层深对比。
3. 国内合规底线：
   • 等保 2.0 要求业务日志≥6 个月，金融交易日志≥5 年；
   • 个人金融信息（PII）事件需可删除（支持 GDPR/PIPL 数据主体请求）。
4. 清理技术路线：
   • Snapshot（快照）+ 归档 + 分区裁剪；
   • 冷热分库、冷数据转 OSS/S3 并建外部表；
   • 增量合并与压缩（Parquet/ORC + ZSTD），保留聚合签名防篡改；
   • 逻辑删除与加密哈希链，满足“可遗忘权”同时保证不可抵赖。
5. 性能测试验证点：
   • 清理作业对在线写入的影不影响：写 TPS 下跌 < 5 %；
   • 重放 1 亿事件耗时对比：清理后恢复时间 RTO 是否满足 SLA；
   • 磁盘空间回收率、索引重建耗时、备份窗口是否可接受。

答案

分五步落地，每一步都给出性能测试验证指标，可直接写进测试报告。

1. 建立快照边界
   按“业务无未完成事务”原则，每天 02:30 触发快照 Job，把聚合根当前状态序列化到 snapshot_table，并记录 last_event_id。
   性能测试验证：快照期间对写入 TPS 影响 < 3 %，快照文件≤5 GB，耗时 < 10 min。

2. 冷热分层归档
   热表按 event_time 做 MySQL 分区（周分区），冷表按季度转 TiDB/OB 历史库，再老化到 OSS 存 Parquet，文件名带 max_event_id 与 SHA-256 摘要。
   性能测试验证：

   • 分区裁剪后，P99 查询 latency 从 1.8 s 降至 120 ms；
   • 归档作业 I/O 峰值 < 磁盘总 IOPS 30 %，备份窗口 03:00-05:00 完成。

3. 合规删除与哈希链
   对含 PII 的事件，采用“逻辑删除+加密哈希链”：在原表新增 erased=1 标识，把原 payload 用 AES-256 打密文后存 erase_log，链式哈希写入 blockchain_service，保证删除后不可篡改。
   性能测试验证：删除 1000 万条事件，耗时 < 40 min，重放验证聚合根终态一致，哈希校验 100 % 通过。

4. 在线裁剪与空间回收
   分区数据>180 天且已有快照，直接 ALTER TABLE DROP PARTITION；InnoDB 打开 innodb_file_per_table 后执行 OPTIMIZE，磁盘空间回收率≥70 %。
   性能测试验证：裁剪 50 亿行，磁盘下降 2.1 TB，期间写 TPS 无抖动，主从延迟 < 1 s。

5. 可追溯重放验证
   随机抽取 3 个季度前的聚合根，用 snapshot + 剩余事件重放，对比终态与生产库 MD5，一致率 100 %；重放 1 亿事件耗时 28 min，满足 RTO≤30 min 的 SLA。
   测试报告结论：清理方案在 TPS、P99、磁盘、合规四维度全部达标，可上线。

拓展思考

1. 如果事件表跨多云（阿里云+华为云），如何设计跨 Region 的归档一致性校验？
2. 当快照本身也达到百亿行，快照表如何再分层（快照-of-快照）？
3. 在 Serverless 架构下（PolarDB Serverless、GaussDB Serverless），自动扩缩容对归档窗口和成本模型的影响如何量化？
4. 事件溯源与流批一体（Flink + Paimon）结合后，归档格式选 Paimon 还是 Iceberg，性能测试应关注哪些新指标？