标签：可用性 原则 解决方案 分区 CAP 一致性 数据 节点
文章目录
概念
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值，
可用性：每一个请求不管成功或者失败都有响应。
分区容错性：因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，不同的区域仍然可以正常访问数据。
一致性以下几种
强一致性又叫原子一致性、线性一致性，要求任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序和实际执行顺序一致。
弱一致性
修改后对该数据的读取操作可能得到更新后的值，也可能是更改前的值。没有严格的顺序性和一致性
最终一致性
要求任何一次读都能读到某个数据的最近一次写的数据。但是最终成功更新的数据都会被所有用户或者进程查询到。简单理解为，就是在一段时间后，数据会最终达到一致状态。
CAP分别落地
一致性
关系型数据库的事务，解决了脏读、幻读、不可重复读的问题，提高顺序一致性。可以把出现不一致的业务整合到一个服务，化分布式事务为本地事务。
服务提供对部分数据的操作的回滚接口，A服务的业务要和B服务的业务同时成功或同时失败，提供回滚接口，就可以在检测到一方成功一方失败后，恢复到未修改前的状态。
对于生产者在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。
可用性
服务降级，当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，给一个备选的响应，不至于一直等待或者报错。
分区容错性
当一个数据项只在一个节点中保存，和这个节点不连通的部分就访问不到这个数据了。如果一个数据项复制到多个节点上，这样在不同的分区都能正常访问数据，分区就有更高的容错性。
满足两项
CAP的矛盾就比如说送外卖，一致性是我点的了什么送什么，可用性就是按时送达，分区容错就是多地配送的支持。矛盾在于点的东西需要做很长时间，按时送达就不能保证点和送的一致性。分区配送路途遥远也会影响送达时间，送达时间长也会影响一致性，点的热菜变凉菜。
CAP要想全部实现，就是要点和送一致，配送时间短距离长，但是在商家与配送还有餐盒保温能力的限制下，舍弃一点能让另外两点发挥到极致，比如我厨房就在你家门口，只给你一个人送饭，这样前两项就发挥到极致，那就成私人厨师了。如果牺牲一点一致性，那么在送餐高峰期就可以简化做菜流程，忽视部分备注少加辣椒还是多加香菜，确保没个点餐的人能迟到饭。最后一种情况就是细致做慢慢送，部分客户等不及退单，牺牲部分可用性。但在现实中不会做这么极端彻底的牺牲，所以就有了比较均衡的策略BASE
CA
在不允许分区，强一致性和可用性是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA，不去做数据的复制。
CP
可用性降低，每个请求都需要在服务器之间保持强一致，等待数据同步完才能正常访问服务，分区同步数据时间无限延长，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。zookeeper集群中leader是不可缺少的，中央集权，有着强一致性，有防止脑裂的方案，解决了分区相关问题。
AP
要高可用性和分区的容错性，则需削减一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而不是数据同步之后的再取值，而这样会导致全局数据的不一致性。非关系型数据库的集群和读写分离，没有事务那样的强一致性，不是实时同步的数据，但能保障最终一直性。Eurka集群各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。
BASE
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性，部分功能降级。
软状态：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
标签：可用性,原则,解决方案,分区,CAP,一致性,数据,节点 来源： https://blog.csdn.net/DT_Zhangshuo/article/details/122818226
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。