微服务间调用失败时，HttpClient
默认重试会破坏业务幂等性
很多团队直接用
HttpClient调用其他微服务，又没配
HttpRequestMessage.Headers.RequestId或业务唯一 ID，一旦网络抖动触发默认重试（比如某些代理或
PolicyHttpHandler配置），下游服务可能收到重复请求。这不是并发问题，是分布式调用链路里“重试 + 无幂等标识”导致的数据不一致根源。 所有跨服务 HTTP 请求必须携带幂等键：
Idempotency-Key: <uuid></uuid>，并在下游服务做去重（如 Redis 缓存
idempotency-key+ TTL） 禁用任何中间层自动重试——把重试逻辑收归业务层，由调用方明确控制：只对
503、
Timeout等可重试错误重试，且必须带相同
Idempotency-Key避免在
HttpClient实例上复用未清理的
HttpRequestMessage，它不是线程安全的；每次请求都新建
HttpRequestMessage
EntityFramework Core
在高并发下提交冲突的真实表现
SaveChangesAsync()不会自动解决并发写冲突，它只会在检测到行版本（
1771666171或
[ConcurrencyCheck]）不匹配时抛
DbUpdateConcurrencyException，而不是静默覆盖。但多数人没捕获这个异常，导致“后写者无声胜出”。 必须显式处理
DbUpdateConcurrencyException：检查
Entries中哪些实体冲突，再决定是刷新再试、合并字段，还是拒绝操作 不要依赖数据库默认隔离级别（SQL Server 是
READ COMMITTED），它不防写覆盖；要用
1771666171字段 +
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，上线后只能靠用户投诉才发现。
