高并发下需分层控制一致性：强一致写用Saga，弱一致读用最终一致；单机同库用SqlTransaction，跨库/服务须避免MSDTC；Redis锁宜用INCR+校验替代RedLock；Outbox比CDC更可控低延迟。
用 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; }
}
分布式一致性的难点不在技术选型，而在业务语义的精确切分——哪些操作必须原子、哪些可以异步补偿、哪些读可以容忍几秒延迟。很多团队卡在“既要强一致又要高性能”，其实是没把“一致性需求”从产品层面拆解清楚。 
