京公网安备11010502063487号实测线性一致与最终一致:etcd 写后立刻读 follower,可串行化读旧值 101 / 300(加 20 ms 延迟后 300 / 300),线性一致读 0 次旧值但延迟从 0.91 ms 到 93.45 ms;Redis 异步复制写后读 replica 旧值 73 / 300,WAIT 1 0 后 0 次;手写线性一致性检查器判定:可串行化读 46 到 100 / 100 段历史不可线性化,线性一致读 0。
用 Redis 主从实测会话一致性:随机读 replica 时读己之写 184 / 1500 次读到旧值,偏移量令牌和写后读 master 都是 0;单调读随机选 replica 倒退 99 次,固定 replica 或记最大值是 0;因果上看到回复读不到帖子 57 / 300 次,检查依赖版本后 0 次。
3 个进程注入 [0, +50, -80] ms 的时钟偏差实测:物理时间戳让 140 / 276 条消息的接收早于发送;Lamport 保证因果但把 87.3% 的并发事件对排出了先后;向量时钟判定 100% 正确但消息头随节点数线性增长;HLC 因果 0 违反,l 与物理时间的差最大 130 ms;物理时钟做 LWW 丢 44.7% 的因果写入。
实测幂等接口的设计:无幂等的 POST 在 100 ms 超时重试下 200 个请求建了 336 个订单(多 136 个);带 Idempotency-Key 后 0 个重复,慢请求走“超时 → 409 → 重放”;同时到达的 100 对只执行 100 次;同 key 不同内容返回 422;key 过期后会再执行一次;PUT + 外部订单号同样 0 重复且不需要 key 表。
实测长事务的代价:MySQL 一致性快照事务让同一行 6 万次更新后它自己的快照读变成 13.46 ms(新会话 0.04 ms),purge 清完用 49.1 s;行锁超时只回滚那条语句,应用没 ROLLBACK 会提交半截修改;持有元数据锁的事务让 ALTER 和后来的普通 SELECT 一起卡 1.72 s;PostgreSQL idle in transaction 让 25000 个死元组清不掉,idle_in_transaction_session_timeout 能让服务器断开它;watchdog 杀掉 5 个超时事务。
用 saga_log 与 saga_step 状态表让 Saga 可观测:1000 个 saga 在 worker 崩溃、临时失败下可以看到每个卡住的 saga 停在哪一步;恢复守护进程抢 owner 接管后 20 个全部走完、对账 0 不一致;支付服务中断 3 秒时在途数涨到 113,2.0 s 触发告警,守护进程接管 104 个,告警 9.1 s 解除。
100 万行的两个库跨库校验:count / sum 会漏一加一减;分桶校验和 1.67 s、传输 1095 KiB 发现全部 50 处差异(全量比较 3.6 s、31.4 MiB);各种汇总方式的盲区;updated_at 增量窗口不重叠会漏 33.7%;抽 1% 行只有 32% 的概率发现 35 处差异。
同一个下单业务的五种实现:单体、朴素拆分、XA、Saga、订单与库存合并。没有失败时 XA 并发只有单体的 0.27x;有 3% 临时失败时朴素拆分留下 149 个订单已确认却缺项,XA、Saga、合并版对账为 0;合并订单与库存后代码从 44 行降到 24 行。