微服务调用需禁用自动重试并强制携带Idempotency-Key；EF Core并发冲突须显式捕获DbUpdateConcurrencyException；Saga本地事务须提交后再发消息并持久化状态；分布式锁必须用带value的SET NX PX及Lua校验释放。
微服务间调用失败时，HttpClient 默认重试会破坏业务幂等性
很多团队直接用 HttpClient 调用其他微服务，又没配 HttpRequestMessage.Headers.RequestId 或业务唯一 ID，一旦网络抖动触发默认重试（比如某些代理或 PolicyHttpHandler 配置），下游服务可能收到重复请求。这不是并发问题，是分布式调用链路里“重试 + 无幂等标识”导致的数据不一致根源。
- 所有跨服务 HTTP 请求必须携带幂等键：
Idempotency-Key:，并在下游服务做去重（如 Redis 缓存idempotency-key+ TTL） - 禁用任何中间层自动重试——把重试逻辑收归业务层，由调用方明确控制：只对
503、Timeout等可重试错误重试，且必须带相同Idempotency-Key - 避免在
HttpClient实例上复用未清理的HttpRequestMessage，它不是线程安全的；每次请求都新建HttpRequestMessage
EntityFramework Core 在高并发下提交冲突的真实表现
SaveChangesAsync() 不会自动解决并发写冲突，它只会在检测到行版本（[Timestamp] 或 [ConcurrencyCheck]）不匹配时抛 DbUpdateConcurrencyException，而不是静默覆盖。但多数人没捕获这个异常，导致“后写者无声胜出”。
- 必须显式处理
DbUpdateConcurrencyException：检查Entries中哪些实体冲突，再决定是刷新再试、合并字段，还是拒绝操作 - 不要依赖数据库默认隔离级别（SQL Server 是
READ COMMITTED），它不防写覆盖；要用[Timestamp]字段 +RowVersion映射，EF 才会在WHERE子句中校验 - 批量更新慎用
ExecuteUpdateAsync：它绕过 EF 的变更跟踪和并发检查，除非你手动拼WHERE Version = @old
Saga 模式里本地事务与补偿事务的边界怎么划
Saga 不是“加个补偿方法就完事”，关键在本地事务提交点和补偿触发时机。比如订单服务扣减库存成功、发消息失败，此时库存已减但订单未创建——补偿动作必须能查到“库存已扣但订单不存在”，否则无法回滚。
- 每个 Saga 步骤的本地事务，必须在发送下一步命令前提交（例如：扣库存事务提交 → 发送
OrderCreated事件） - 补偿事务不能只依赖“逆向操作”，要查当前状态：补偿扣库存前，先查订单是否真的未创建，避免重复补偿
- 用持久化 Saga 日志（如数据库表
SagaInstance）记录每步状态，而不是靠内存或临时队列；否则服务重启后无法续跑或补偿
public class OrderSaga : ISaga
{
public async Task Execute(StartOrderCommand cmd)
{
// 1. 本地事务：扣库存（含并发检查）
await _inventoryContext.SaveChangesAsync(); // 抛 DbUpdateConcurrencyException 可捕获
// 2. 提交后才发事件，确保库存已扣
await _publisher.Publish(new InventoryDeducted(cmd.OrderId, cmd.Items));
// 3. 记录 saga 当前步到 DB（非内存）
await _sagaRepository.SaveStep(cmd.OrderId, "InventoryDeducted", Status.Completed);
}
}
分布式锁选型：Redis RedLock 已不推荐，SET NX PX 也得加 client ID
用 StackExchange.Redis 的 LockTake 时，很多人只传 key 和 timeout，没传唯一 value（如 Guid.NewGuid().ToString()），导致锁被别人误删——这是最常被忽略的细节。
- 必须用
SET key value NX PX 30000形式获取锁，并在释放时用 Lua 脚本比对 value 再删：if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end - 避免用
RedLock：它在 Redis Cluster 分片故障时有脑裂风险，官方已标记为 legacy；单节点 Redis + 正确的SET语义更可靠 - 锁超时时间不能拍脑袋定——要大于最长业务执行时间 + 网络毛刺余量；否则锁自动释放后，另一个实例进来，两份逻辑同时跑
真实场景里，数据一致性崩塌往往不在代码逻辑，而在跨服务调用的隐式假设、本地事务的提交时机、以及锁释放的竞态条件。这些地方没日志、不压测、不看 trace，上线后只能靠用户投诉才发现。