慕课网站建设开题报告,厦门建设厅网站,app是程序员做出来的吗,app制作教程步骤和方法目录 一、什么是CAP#xff1f; Consistency (一致性)#xff1a; Availability (可用性): Partition Tolerance (分区容错性): 二、取舍策略 三、Base理论 1、基本可用 2、软状态 3、最终一致性 四、常见产品 Ereka Zookeeper 五、总结 一、什么是CAP#xf…目录 一、什么是CAP Consistency (一致性)  Availability (可用性): Partition Tolerance (分区容错性): 二、取舍策略 三、Base理论 1、基本可用 2、软状态 3、最终一致性 四、常见产品 Ereka Zookeeper 五、总结 一、什么是CAP Consistency (一致性)  “All nodes see the same data at the same time”即更新操作成功并返回客户端后所有节点在同一时间的数据完全一致这就是分布式的一致性。一致性的问题在并发系统中不可避免对于客户端来说一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看则是更新如何复制分布到整个系统以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”即服务一直可用而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了其他剩下的机器还能够正常运转满足系统需求对于用户而言并没有什么体验上的影响。 二、取舍策略 CAP三个特性只能满足其中两个那么取舍的策略就共有三种 CA without P如果不要求P不允许分区则C强一致性和A可用性是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性也就是分布式节点受限没办法部署子节点这是违背分布式系统设计的初衷的。 CP without A如果不要求A可用相当于每个请求都需要在服务器之间保持强一致而P分区会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)一旦发生网络故障或者消息丢失等情况就要牺牲用户的体验等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少最典型的就是分布式数据库如Redis、HBase等。对于这些分布式数据库来说数据的一致性是最基本的要求因为如果连这个标准都达不到那么直接采用关系型数据库就好没必要再浪费资源来部署分布式数据库。 AP wihtout C要高可用并允许分区则需放弃一致性。一旦分区发生节点之间可能会失去联系为了高可用每个节点只能用本地数据提供服务而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景可能前几秒你浏览商品的时候页面提示是有库存的当你选择完商品准备下单的时候系统提示你下单失败商品已售完。这其实就是先在 A可用性方面保证系统可以正常的服务然后在数据的一致性方面做了些牺牲虽然多少会影响一些用户体验但也不至于造成用户购物流程的严重阻塞。 三、Base理论 BASE是Basically Available基本可用、Soft state软状态和Eventually consistent最终一致性三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果其来源于对大规模互联网系统分布式实践的总结 是基于CAP定理逐步演化而来的。BASE理论的核心思想是即使无法做到强一致性但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素 1、基本可用 基本可用是指分布式系统在出现不可预知故障的时候允许损失部分可用性—-注意这绝不等价于系统不可用。比如 1响应时间上的损失。正常情况下一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果但由于出现故障查询结果的响应时间增加了1~2秒 2系统功能上的损失正常情况下在一个电子商务网站上进行购物的时候消费者几乎能够顺利完成每一笔订单但是在一些节日大促购物高峰的时候由于消费者的购物行为激增为了保护购物系统的稳定性部分消费者可能会被引导到一个降级页面 2、软状态 软状态指允许系统中的数据存在中间状态并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时 3、最终一致性 最终一致性强调的是所有的数据副本在经过一段时间的同步之后最终都能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致而不需要实时保证系统数据的强一致性。总的来说BASE理论面向的是大型高可用可扩展的分布式系统和传统的事物ACID特性是相反的它完全不同于ACID的强一致性模型而是通过牺牲强一致性来获得可用性并允许数据在一段时间内是不一致的但最终达到一致状态。但同时在实际的分布式场景中不同业务单元和组件对数据一致性的要求是不同的因此在具体的分布式系统架构设计过程中ACID特性和BASE理论往往又会结合在一起。 四、常见产品 Ereka Ereka是SpringCloud系列用来做服务注册和发现的组件作为服务发现的一个实现在设计的时候就更考虑了可用性保证了AP。 Zookeeper Zookeeper在实现上牺牲了可用性保证了一致性单调一致性和分区容错性也即CP。 所以这也是SpringCloud抛弃了zookeeper而选择Ereka的原因。 五、总结 对于分布式系统的项目使用中没有强制要求一定是CAP中要达到某几种具体根据各自业务场景所需来制定相应的策略而选择适合的产品服务等。例如支付订单场景中由于分布式本身就在数据一致性上面很难保证从A服务到B服务的订单数据有可能由于服务宕机或其他原因而造成数据不一致性。因此此类场景会酌情考虑AP不强制保证数据一致性但保证数据最终一致性。