CAP定理指出，分布式系统不可能同时很好地满足一致性(C)、可用性(A)和分区容错性(P)这三个属性。
根据CAP来设计分布式系统：
-
CP系统优先保证一致性，允许可用性下降，如分布式锁、分布式事务等。
-
AP系统优先保证可用性，允许一致性下降，如CDN内容分发网络。
-
最佳实践是根据业务场景权衡C和A。
后来Amazon提出了BASE理论，即Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致)。
-
基本可用：尽量保持系统运行，允许短暂不一致。
-
软状态：数据可以有一段时间内处于不一致状态。
-
最终一致：通过事件ual处理和同步，最终可以达成强一致状态。
比如：
- 购物车：SESSION保证一致性
- 评论：最终一致即可
- 账户余额：强一致
具体应用：
- NoSQL数据库如MongoDB支持可用性与最终一致
- 缓存支持Session保持一致
- 消息队列支持最终一致模型
- 服务注册支持高可用
总体来说，CAP与BASE为分布式系统设计提供了很好的指导原则。
这里给CAP理论和BASE理论在分布式系统中的应用增加一些其他技术点：
- 数据分片
通过垂直或水平切分，实现单点资源下的高可用和扩展性。
- 本地缓存
利用缓存提高读性能，通过一致性协议保证最终一致。
- 读写分离
读操作路由到从库，提高吞吐量同时保证最终一致。
- 消息队列
通过消息中间件实现异步和解耦，支持最终一致模型。
- 服务注册中心
比如Etcd或Zookeeper提供分布式锁和一致性读写，支持CP和AP应用。
- 版本控制
通过版本号追踪数据变更历史，解决并发写问题。
- 消息处理框架
比如Kafka支持分区与重复消费，满足大数据实时处理。
- 分布式协调
通过Raft或Paxos等算法实现强一致分布式系统。
- 面向事件的架构
如CQRS和ES支持最终一致和高并发读写。
- 容错机制
如链路熔断、降级、重试等保证整体系统可用性。
综上，CAP和BASE为分布式系统设计提供很好的指导，在上述各个层面都有很好的应用。
