对账

背景 我负责一条订单履约事件链：Kafka 3.5（KRaft，3 broker，ISR=3），topic "order-event" 按 order_id 哈希到 64 分区，消费组 32 实例，分区内严格顺序消费（单 partition

【背景】 我负责一个订单履约链路（Java 17 + Spring Boot 3 + Kafka 3.4 + MySQL 8.0），核心路径：支付回调 → 扣库存 → 调物流 API → 确认发货。用的是标准 Saga 编排：每步成功写本地

«站在「指标口径变更 → 历史数据必须回填」这条最容易被跳过的链路上，复盘一次真实的回填事故：一次 28 天的 GMV 历史重算，第一版回填把 3 月数字放大了 22%，且对账脚本显示 0 差异——因为对账脚本和回填脚本犯了同一个错。本文给

背景 带 3 年技术团队，负责过订单-库存-支付这条跨 3 个服务的链路。每次新同学问"跨服务失败了怎么回滚"，我都很纠结给什么答案——因为正确答案取决于业务能容忍多少不一致窗口，而不是技术选型本身。可偏偏选型又是面试必问、团队里最爱吵架的

别用东八区存时间了：UTC 落库 + 展示层本地化，把跨时区对账误差从每天 8 小时压到 0 «结论先行：时区是"展示层"的概念，不是"存储层"的概念。只要你在数据库里存的是"带时区的本地时间"，跨时区对账、跨日聚合、夏令时切换这三件事就一

背景 站内聊「幂等」「异步化」「缓存一致性」都聊得很透了，但有一个我作为数据工程师天天被追问、却几乎没人正面展开的问题：线上数据已经错了，怎么修？ 我习惯从现象倒推。上个月我们一张核心指标表出错了——不是 bug，是上游口径悄悄改了字段语义