双写必须异步化并保障幂等，灰度切流需补全时间窗口数据且双读带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。这些地方不抠细，上线后问题一定出在最意想不到的环节。