双写必须异步化并保障幂等，灰度切流需补全时间窗口数据且双读带fallback，最终一致延迟须按场景设定阈值并监控端到端耗时，事务消息仅保证发与本地事务一致，不保下游消费成功。
双写时怎么保证服务不互相拖垮
微服务双写本质是让两个服务同时写两套存储，但order-service往 MySQL 写完，再调用 inventory-service 的 HTTP 接口扣库存，一旦后者响应慢或超时，前者就卡住——这不是最终一致，是直接雪崩。
- 双写必须异步化：
order-service写完本地 DB 后，只发一条消息到kafka或rocketmq，不等下游返回 - 消费端要做幂等：
inventory-service收到重复消息不能多扣，得靠order_id+version或数据库INSERT IGNORE - 别在双写链路里加强一致性校验：比如写完立刻查对方状态，这等于把最终一致退化成强一致，延迟和失败率都翻倍
灰度切流后新老数据不一致怎么办
切流不是开关一拨就完事。比如 10% 流量切到新订单服务，但老服务还在写旧库，新服务写新库，中间没同步，用户查历史订单看到的是旧数据，查新订单却是新格式，字段对不上。
- 必须提前补全「时间窗口」数据：在切流前，用离线任务把老库中最近 7 天的
order表全量同步到新库，且打上source=legacy标记 - 切流期间双读要带 fallback：新服务查新库没结果，再查一次老库，但仅限读，绝不反向写回
- 禁止跨库 join：别在应用层拼接新老库数据，容易漏、慢、错；聚合逻辑统一收口到 API 网关或单独的
order-view-service
最终一致的延迟到底能忍多久
很多人以为“最终一致”就是“随便晚点”，其实业务对延迟极其敏感。比如支付成功后 3 秒内库存没扣减，就可能超卖；用户改地址后 30 秒才同步到物流系统，快递单就打错了。
- 延迟阈值得按场景定：
inventory类必须 user-profile 类可放宽到 5s，log-audit类可以分钟级 - 监控必须落到具体链路：不只是看
kafka消费 lag，还要埋点测从order_created事件发出，到inventory_decreased被消费完成的端到端耗时 - 有延迟就要有补偿：超过阈值自动触发
reconcile_job，但 job 本身不能依赖实时消息，得查 DB 快照+时间范围，避免无限重试
为什么事务消息没解决双写一致性
用了 rocketmq 的事务消息，order-service 还是会丢数据：半消息发出去了，本地事务 commit 成功，但 check 方法没写对，或者 broker 重启后找不到事务状态，消息就卡死。
-
check方法不能只查 DB 状态，得查“有没有生成对应业务单据”，比如确认order_status = 'paid'且payment_id非空 - 半消息有效期别设太长：默认 6 小时太危险，改成
2min，超时直接转DEAD_LETTER，由人工介入或定时扫描兜底 - 事务消息只保“发出去”和“本地事务”一致，不保下游消费成功：下游失败还得靠死信队列 + 手动重投，别指望它自动重试 16 次就万事大吉
双写不是加个消息队列就高枕无忧，灰度切流也不只是配个 nginx 权重。真正卡脖子的，永远是那几个没写进文档的边界条件：时钟不同步导致的幂等失效、DB 快照与消息时间戳错位、补偿任务跑一半挂掉又没记录 checkpoint。这些地方不抠细，上线后问题一定出在最意想不到的环节。
