微服务调用需禁用自动重试并强制携带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() 不会自动解决并发写冲突，它只会在检测到行版本（1768758336 或 [ConcurrencyCheck]）不匹配时抛 DbUpdateConcurrencyException，而不是静默覆盖。但多数人没捕获这个异常，导致“后写者无声胜出”。

• 必须显式处理 DbUpdateConcurrencyException：检查 Entries 中哪些实体冲突，再决定是刷新再试、合并字段，还是拒绝操作
• 不要依赖数据库默认隔离级别（SQL Server 是 READ COMMITTED），它不防写覆盖；要用 1768758336 字段 + 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 语义更可靠
• 锁超时时间不能拍脑袋定——要大于最长业务执行时间 + 网络毛刺余量；否则锁自动释放后，另一个实例进来，两份逻辑同时跑