CP策略在C#微服务中需借助ZooKeeper或etcd实现强一致，注意会话超时配置、锁内避免耗时IO、etcd租约续期；AP场景须量化最终一致性SLA、用对账补偿和可靠消息队列；EF Core跨库事务天然失效，应选Saga或本地消息表；软状态须有明确生命周期与收敛路径，不可滥用缓存。
CP策略在C#微服务中怎么落地？用 ZooKeeper 或 etcd 做协调器时要注意什么
在C#系统里实现CP（强一致+分区容错），典型做法是引入外部一致性协调服务，比如用 Curator（通过.NET包装）连ZooKeeper，或用 etcdnet 客户端连etcd。它们不是靠数据库事务兜底，而是靠分布式锁、临时节点、Watch机制来保证操作的串行化。
- 写支付订单前必须先
acquire一个路径如/lock/order/{orderId}，超时未获取则直接失败——这直接体现“牺牲可用性保一致” - 不要在锁内做耗时IO（如HTTP调用、DB长查询），否则锁持有时间不可控，导致大量请求排队甚至雪崩
- ZooKeeper的会话超时默认是30秒，但C#客户端若没显式设置
SessionTimeoutMs，可能因GC暂停或网络抖动被误踢出，引发锁自动释放——这是线上高频故障点 - etcd的
Lease+CompareAndSwap更适合.NET生态，但要注意：Put操作带租约后，必须定期KeepAlive，否则锁无声失效
AP场景下，C#怎么避免“最终一致性”变成“永远不一致”
C#项目选AP路线（比如用 DynamoDB 或 Cassandra + 自研同步管道），核心不是“放任不一致”，而是把不一致控制在可观察、可补偿、有退路的范围内。
- 所有异步更新必须带唯一
eventId和时间戳，写入消息队列（如RabbitMQ或Azure Service Bus）时启用DeadLetterQueue，否则失败消息直接丢弃，最终一致性就真成“最终消失”了 - 库存扣减和订单创建分离时，不能只靠“下单成功→发MQ→扣库存”单向流；必须加对账Job：每5分钟扫描
OrderStatus = 'CREATED'且InventoryDeducted = false的记录，触发补偿 -
Task.Run(() => UpdateInventoryAsync())是反模式——它脱离了请求上下文，失败无日志、无重试、无监控。应该用IHostedService+BackgroundService管理后台任务生命周期 - 最终一致性的“最终”，要量化：电商库存通常要求
≤ 2s，用户资料同步可放宽到≤ 30s；这个SLA必须体现在接口文档和监控告警中，而不是口头约定
EntityFramework Core 事务 vs 分布式事务：为什么ACID在C#跨库场景下天然失效
很多C#开发者以为用 DbContext.Database.BeginTransaction() 就能搞定多库一致性，其实这只在单数据库实例内有效。一旦涉及SQL Server + PostgreSQL，或SQL Server + Redis缓存，EF Core的事务完全不起作用。
- EF Core的
SaveChangesAsync()提交的是本地事务，不是XA；跨库操作本质是多个独立事务，没有两阶段提交（2PC）协调者 - 想强行用
TransactionScope包裹多个DbContext，会触发MSDTC（Microsoft Distributed Transaction Coordinator），但在容器/K8s环境默认禁用，且性能极差（RTT翻倍、锁持有时间拉长） - 真实可行的替代方案只有两个：
Saga模式（用状态机+补偿事务，推荐MassTransit库）或本地消息表（在主库建Outbox表，用定时任务投递，避免跨库） - 别信“EF Core 8支持分布式事务”的宣传——它只是增强了对
TransactionScope的兼容性，底层仍依赖MSDTC，没解决根本问题
BASE里的“软状态”在C#代码里怎么体现？别把缓存当软状态滥用
很多人把Redis缓存简单等同于BASE的“软状态”，结果缓存击穿+DB压力暴涨，反而破坏了“基本可用”。真正的软状态，是系统主动设计的、有明确生命周期和收敛路径的中间态。
- 用户登录态用JWT而非Session，就是一种软状态：token过期前数据不变，但服务端不维护其生命周期——符合
Soft State定义 - 商品详情页的“销量”字段，可以设计为：DB里存准确值，Redis里存带TTL的近似值（如每10分钟异步更新一次），前端优先读Redis，降级时读DB——这是可控的软状态
- 错误做法：把用户余额全放Redis，靠应用层定时刷DB。一旦刷新中断，余额就永久失真，这不是软状态，是单点故障
- C#里用
MemoryCache实现软状态时，务必设置ExpirationTokens关联DB变更事件（如SqlDependency），而不是只靠绝对过期时间
await、每一个 lock、每一次 TryAdd，都在悄悄填写这张表——填错的地方，不会立刻报错，但会在大促零点、机房断网、磁盘满载时，以最意想不到的方式浮现。 
