用 TransactionScope
做本地事务不够，高并发下必须分层控制
单机
TransactionScope在跨服务或跨数据库时会退化为 MSDTC，不仅性能差，还容易因网络抖动导致长时间悬挂甚至死锁。真正高并发场景下，不能靠“加锁+事务”硬扛，得按读写特征分层：强一致写路径用分布式事务协调（如 Saga），弱一致读路径接受最终一致（如 CDC + 缓存双删）。 订单创建、支付扣减这类有明确业务生命周期的操作，优先走
Saga模式——每个步骤自带补偿接口，失败时正向回滚而非全局锁表 库存扣减若要求实时强一致，需结合
Redis Lua脚本做原子预占（
DECRBY+ 条件判断），避免先查后减的竞态 SQL Server 上慎用
SELECT ... WITH (UPDLOCK, HOLDLOCK)，它在高并发下极易引发锁升级成表锁，反而拖垮吞吐
SqlTransaction
和 DistributedTransaction
的实际边界在哪
只要所有操作都在同一个 SQL Server 实例、同一个连接字符串下，
SqlTransaction就够用；一旦涉及跨库（哪怕同实例不同 DB）、跨服务（如调用下游 HTTP 接口完成扣款）、或使用了 Entity Framework Core 的多上下文提交，就必须放弃自动提升的
DistributedTransaction——它依赖 MSDTC，而 Windows Server 2016+ 默认禁用，且 .NET 6+ 已明确标记
TransactionManager.DistributedTransactionStarted为过时。 EF Core 中多个
DbContext实例无法共用一个
SqlTransaction，必须手动传入
DbConnection和
SqlTransaction构造新上下文 跨 HTTP 调用时，用请求头透传
X-Request-ID和
X-Trace-ID，下游通过幂等键（如
order_id + action_type）实现接口级去重，比强求分布式事务更可靠 不要在异步方法中捕获
TransactionAbortedException后尝试重试——事务已不可恢复，应立即返回失败并触发补偿
用 Redis
实现分布式锁时，SETNX
和 RedLock
都不推荐
.NET SDK 自带的
StackExchange.Redis提供了
LockTake/
LockRelease，底层基于
SET key value EX seconds NX，但仅适用于单 Redis 实例。集群模式下
RedLock因时钟漂移和 GC 暂停已被作者否决；而用 ZooKeeper 或 Etcd 做锁服务又引入新运维成本。更务实的做法是：用
Redis的
INCR+ 过期时间模拟乐观锁，配合业务层重试。 例如秒杀库存，用
INCR stock:1001获取当前占用数，再与总量比对；不是“抢到锁才操作”，而是“操作前校验余量” 避免在锁内做 HTTP 调用或文件 IO，锁持有时间超过 500ms 就大概率成为瓶颈 绝不使用
GET + DEL判断锁状态——这是经典竞态漏洞，必须用
EVAL脚本保证原子性
最终一致性方案里，CDC
和 Outbox
怎么选
两者都解决“本地事务成功后，如何可靠通知下游”的问题，但实现粒度不同：
Outbox是应用层模式，在主事务中写一条消息记录到本地
Outbox表，再由后台轮询投递；
CDC（如 Debezium）监听数据库日志，零侵入捕获变更。前者可控性强、延迟低（毫秒级），后者部署重、首次同步慢，但能覆盖所有数据源变更（包括手工 SQL 修改）。 如果用 SQL Server，优先实现
Outbox：在 EF Core SaveChanges 前插入
OutboxMessage实体，用同一事务提交，再通过
BackgroundService拉取未发送消息 避免用
SqlDependency做变更通知——它依赖 Service Broker，容易因队列积压或权限问题静默失败 投递失败的消息必须进死信队列（如 RabbitMQ 的
DLX），并提供人工干预入口，不能无限重试导致下游重复消费
// Outbox 消息实体示例（EF Core）
public class OutboxMessage
{
public Guid Id { get; set; }
public string Type { get; set; } // "OrderCreated"
public string Content { get; set; } // JSON 序列化内容
public DateTime CreatedAt { get; set; }
public DateTime? ProcessedAt { get; set; }
}
分布式一致性的难点不在技术选型，而在业务语义的精确切分——哪些操作必须原子、哪些可以异步补偿、哪些读可以容忍几秒延迟。很多团队卡在“既要强一致又要高性能”，其实是没把“一致性需求”从产品层面拆解清楚。 
