- 场景：银行转账、股票交易、跨境支付等。
- 核心需求：
- 数据一致性：确保交易金额在发送方和接收方账户同步更新，避免出现 “单边账”（如 A 账户扣款成功但 B 账户未到账）。
- 原子性：交易必须全部成功或全部失败，例如支付过程中若网络中断，需回滚已执行的操作。
- 技术实现：
- 采用分布式事务（如 XA 协议）或强一致性数据库（如 MySQL InnoDB）。
- 牺牲部分可用性（如短暂冻结账户）以保证数据同步，例如银行系统在网络分区时暂停新交易。
- 场景：航空公司的实时订票系统、酒店预订平台。
- 核心需求：
- 库存唯一性：同一航班座位或酒店房间不能被多个用户同时预订。
- 跨渠道一致性：官网、代理商、移动端等多渠道数据需实时同步。
- 技术实现：
- 使用分布式锁（如 Redis Redlock）或悲观锁机制，确保同一时间只有一个请求修改库存。
- 网络分区时暂停新订单，直到数据同步完成。
- 场景：医院电子病历系统、企业核心财务数据库。
- 核心需求：
- 数据完整性：医疗记录的任何修改必须在所有副本节点同步，避免误诊风险；财务数据需符合审计要求。
- 不可篡改性：数据一旦写入，后续修改需全程可追溯。
- 技术实现：
- 采用强一致性分布式数据库（如 Google Spanner）或区块链技术。
- 通过 Paxos、Raft 等共识算法保证数据在网络分区时的一致性。
- 场景：电商大促期间的库存扣减、制造业原材料调度。
- 核心需求：
- 库存精准性：避免超卖（如某商品显示有货但实际已售罄）。
- 跨仓库同步：多仓库库存数据需实时一致，例如用户下单后自动分配最近仓库的可用库存。
- 技术实现：
- 使用分布式事务或消息队列（如 Kafka）实现最终一致性，结合库存预占机制。
- 网络分区时暂停库存修改，优先保证数据准确。
- 场景：微博、微信朋友圈、直播弹幕。
- 核心需求：
- 用户体验优先：允许短暂的数据不一致（如用户 A 发布的内容在部分节点延迟显示），但需保证操作无阻塞。
- 高并发处理：支持百万级用户同时在线发布、点赞、评论。
- 技术实现：
- 采用最终一致性（如异步消息队列），通过补偿机制解决数据不一致。
- 网络分区时允许部分功能降级（如仅展示本地缓存数据）。
- 场景：淘宝、京东的商品列表页、个性化推荐系统。
- 核心需求：
- 快速响应：用户搜索商品时需毫秒级返回结果，即使不同节点的数据略有差异（如价格、库存）。
- 流量洪峰应对：大促期间需支撑每秒数万次查询请求。
- 技术实现：
- 使用缓存（如 Redis）和分布式搜索引擎（如 Elasticsearch）提升性能。
- 网络分区时优先返回本地缓存数据，后续异步同步更新。
- 场景：Ceph、GlusterFS 等存储系统，日志收集服务（如 ELK）。
- 核心需求：
- 读写无阻塞：用户上传文件或写入日志时，即使部分节点不可用，仍可继续操作。
- 数据最终一致：允许不同节点的数据暂时不一致，但需通过复制机制最终同步。
- 技术实现：
- 采用纠删码（Erasure Coding）或多副本策略保证数据冗余。
- 网络分区时允许读写操作，后续通过数据同步修复差异。
- 数据一致性要求：
- CP 系统适用于数据错误代价极高的场景（如金融交易、医疗记录）。
- AP 系统适用于用户体验优先、可容忍短暂不一致的场景（如社交互动、商品搜索）。
- 业务连续性需求：
- CP 系统可能因数据同步导致服务短暂中断（如银行系统维护）。
- AP 系统通过降级策略保证服务可用（如电商大促时隐藏库存细节）。
| 维度 | CP 系统 | AP 系统 |
|---|
| 一致性 |
强一致性（所有节点数据同步） |
最终一致性（允许短暂不一致） |
| 可用性 |
可能因数据同步降低可用性 |
高可用性（允许部分功能降级） |
| 典型技术 |
分布式事务、Paxos/Raft 算法 |
异步消息队列、缓存、最终一致性补偿 |
| 性能 |
较低（需等待所有节点确认） |
较高（无需等待所有节点确认） |
- CP 系统：适用于数据一致性要求极高、允许牺牲部分可用性的场景，如金融、医疗、航空订票等。
- AP 系统：适用于高并发、用户体验优先、可容忍短暂不一致的场景，如社交网络、电商搜索、分布式文件系统等。
核心原则：根据业务场景的数据一致性需求和可用性优先级选择策略，而非绝对追求 “CP 更优” 或 “AP 更优”。例如：
- 某银行选择 CP 系统，确保转账交易的绝对准确；
- 某电商平台选择 AP 系统，通过异步同步库存数据，优先保证大促期间的用户下单体验。
实际项目中，还可结合混合策略（如关键业务用 CP，非关键业务用 AP）或通过中间件（如消息队列）平衡一致性和可用性。
浙公网安备 33010602011771号