cap原理按照定义，指的是c（consistency）一致性，a（availability）可用性，p（partition tolerance）分区容错性在一个完整的计算机系统中三种特性不能同时得到完全满足。
consistency（（强）一致性）：指的是在同一时间点，所有的数据状态是否是一致的。对于一致性的理解，个人认为可以从关系型数据库的事务概念出发来进行理解。例如：一次银行账户的转账，双方账户的金额必须同时增加，和减少。不能出现转账账户已经扣钱，而被转账账户未能增加金额的情况。
availability（（高）可用性）：顾名思义，指的是计算机系统特别的好用，总是能满足用户的需求（接受更多请求，响应更快），用形式化的语言描述就是系统拥有非常高的非故障运行时间百分率。这一特性在如今互联网时代，海量用户，大并发请求的场景下对于计算机系统显得尤为重要，毕竟没有用户喜欢一到高峰时期就停止响应的系统。
partition tolerance（分区容错性）：指的是在整个系统拥有两台或以上数量的计算机单元提供服务，当其中部分分区节点故障时，整个系统依然可以向用户提供可靠的服务。
cap定理告诉我们cap这三种特性不能同时完全满足,因此存在以下三种取舍情况：
1.选择ca，放弃p
通常是由一台非常强大的计算机对外提供服务来保证a（高可用性），所有的数据操作都在同一台机器上。在上面提到的银行账户转账例子中，在数据库层面上通过本地事务来轻松满足c（（强）一致性）。试想如果此时想要拥有p，即转账双方位于不同分区，那么一旦被转账方出现故障，要么耗费时间等待其重新开始服务（放弃a）；或者暂时仅仅处理转账方的业务，等待后续的一致性补偿操作（放弃c）。
该方案的缺点：由于目前科学技术上的限制，无法横向扩容的系统是无法应付海量请求，大并发的场景的，同时也容易导致单点故障出现，因此这里的a（高可用性）实际上是大打折扣的。
2.选择cp，放弃a。
意味着系统在提供服务时，一旦出现分区故障，为了确保数据的强一致性，所涉及到的服务全部都会停止响应，因此a（高可用性）也就不复存在啦。暂时还没有想到什么场景下会采取这种方案。
该方案的缺点：个人认为低可用性本身就是系统的一大缺点。
3.选择ap，放弃c。这种架构可以说是如今互联网时代最流行的架构。通过分布式和集群进行横向的系统性能拓展，尽可能的舍弃对数据强一致性的需求，同时在遇到不可避免的分布式事务场景时，大牛们也已经提出了各种各样的方案来满足最终的数据一致性（（弱）一致性），就不再这里展开说明了。
该方案的缺点：不适合对数据一致性c（（强）一致性）有极高要求的场景，以及不追求a（高可用性）要求的场景（分区总是会带来额外的麻烦）。
其实，选择ap而放弃c的设计理念并不仅仅适用于整个系统的整体架构，例如在系统内部，数据库集群（可以理解为一个子系统）主从分离的同步延迟造成从库数据与主库数据出现数据暂时不一致的情况等等。
除此之外，cap中的三个元素也并不是完全的互斥，例如选择ap，其实也不是彻底的放弃了c（一致性），而是进行了一定程度的让步，同时c（一致性）也能细分为读一致性，写一致性等。因此不能机械的将cap理论理解为完全互斥，三选二，而是在这三个维度上面进行不同程度的取舍。个人认为cap理论其实是告诉人们天下没有免费的午餐，也不存在完美无缺的系统设计，需要反复的斟酌，权衡，才能设计出合理的，符合需求的系统架构。
以上是我对cap原理的一些理解，存在不少误区，欢迎交流。
如对本文有疑问， 点击进行留言回复！！
Spring Cloud Alibaba系列，nacos作为服务配置中心
Spring Cloud Alibaba系列（一）nacos作为服务注册中心
我要评论
网友评论