北京网站建设一条龙wordpress的文章多重筛选
news/
2025/9/23 3:37:40/
文章来源:
北京网站建设一条龙,wordpress的文章多重筛选,北京十大企业公司排名,山东seo网站CAP理论
CAP理论#xff0c;对分布式系统的特性做了高度抽象#xff0c;比如抽象成了一致性、可用性和分区容错性#xff0c;并对特性间的冲突#xff08;也就是CAP不可能三角#xff09;做了总结。
CAP三指标
CAP理论对分布式系统的特性做了高度抽象#xff0c;形成了…CAP理论
CAP理论对分布式系统的特性做了高度抽象比如抽象成了一致性、可用性和分区容错性并对特性间的冲突也就是CAP不可能三角做了总结。
CAP三指标
CAP理论对分布式系统的特性做了高度抽象形成了三个指标
一致性Consistency可用性Availability分区容错性Partition Tolerance
一致性指的是客户端的每次读操作不管访问哪个节点要么读到的都是同一份最新写入的数据要么读取失败。
可用性指的是任何来自客户端的请求不管访问哪个非故障节点都能得到响应数据但不保证是同一份最新数据。这个指标强调的是服务可用但不保证数据正确。
分区容错性指的是当节点间出现任意数量的消息丢失或高延迟的时候系统仍然在继续工作。也就是说分布式系统在告诉访问本系统的客户端不管我的内部出现了什么样的数据同步问题我会一直运行。这个指标强调的是集群对分区故障的容错能力。 在分布式系统中分区容错性是必须要考虑的。 CAP不可能三角
CAP 不可能三角说的是对于一个分布式系统而言一致性Consistency、可用性Availability、分区容错性Partition Tolerance3 个指标不可兼得只能在 3 个指标中选择 2 个。 如何使用CAP理论
只要有网络交互就一定会有延迟和数据丢失而这种状况必须接受还必须保证系统不能挂掉。所以节点间的分区故障是必然发生的。也就是说分区容错性P是前提是必须要保证的。
那么剩下一致性C和可用性A可以选择了要么选择一致性保证数据正确要么选择可用性保证服务可用。
当选择了一致性C的时候一定会读到最新的数据不会读到旧数据但如果因为消息丢失、延迟过高发生了网络分区那么这个时候当集群节点接收到来自客户端的读请求时为了不破坏一致性可能会因为无法响应最新数据而返回出错信息。当选择了可用性A的时候系统将始终处理客户端的查询返回特定信息如果发生了网络分区一些节点将无法返回最新的特定信息它们将返回自己当前的相对新的信息。 许多人认为无论在什么情况下分布式系统都只能在C和A中选择1个。其实在分布式系统正常运行时就是说在不需要P时C和A能够同事保证。只有当发生分区故障的时候也就是说需要P时才会在C和A之间做出选择。 小结
CA模型在分布式系统中不存在。因为舍弃 P意味着舍弃分布式系统就比如单机版关系型数据库 MySQL如果 MySQL 要考虑主备或集群部署时它必须考虑 P。
CP模型采用 CP 模型的分布式系统舍弃了可用性一定会读到最新数据不会读到旧数据。一旦因为消息丢失、延迟过高发生了网络分区就影响用户的体验和业务的可用性比如基于 Raft 的强一致性系统此时可能无法执行读操作和写操作。典型的应用是 EtcdConsul 和 Hbase。
AP模型采用 AP 模型的分布式系统舍弃了一致性实现了服务的高可用。用户访问系统的时候都能得到响应数据不会出现响应错误但会读到旧数据。典型应用就比如 Cassandra 和 DynamoDB。 在当前分布式系统开发中延迟是非常重要的一个指标比如在 QQ 后台的名字路由系统中通过延迟评估服务可用性进行负载均衡和容灾再比如在 Hashicorp/Raft 实现中通过延迟评估领导者节点的服务可用性以及决定是否发起领导者选举。所以在分布式系统的开发中需要意识到延迟的重要性能通过延迟来衡量服务的可用性。 ACID理论
ACID理论可以看成是对事务特性的抽象和总结方便实现事务。可以理解为如果实现了操作的ACID特性那么就实现了事务。在单机上实现事务并不难如可以通过锁、时间序列等机制保障操作的顺序执行让系统实现ACID特性。但在分布式系统中比较困难因为分布系统涉及多个节点间的操作。加锁、时间序列等机制只能保证单个节点上的ACID特性无法保证节点间操作的ACID特性。
通过分布式事务协议如二阶段提交协议和**TCCTry-Confirm-Cancel**可以实现分布式系统上的ACID特性。 问题 如何保证节点A、B、C执行分布式事务操作X要么全部执行要么全部不执行。 二阶段提交协议
二阶段提交协议2pc就是通过二阶段的协商来完成一个提交操作具体的操作如下
客户端发送消息给节点A节点A收到消息后就扮演协调者Coordinator的身份由节点A通信节点B和节点C发起二阶段提交。 第一阶段为提交请求节点又称投票阶段。首先节点A向节点B和节点C发送消息“能否执行操作X”节点B和节点C判断 能否执行操作X如果可以就预留一部分资源给操作X。最后将能否执行操作X发送给节点A节点A收到全部的回复结果包括自己的结果这里假设全都是能够执行的回复。 第二阶段为提交执行阶段又称完成阶段也就是执行具体的操作了。首先节点A按照要么全部执行要么全部放弃的原则统计回复结果由于所有的回复结果都是能够执行所以节点A决定执行分布式事务操作X。然后通知节点B、节点C执行操作X。节点B和节点C在收到通知后执行事务操作X。最后节点B和节点C将执行事务的结果返回给节点A。 在第一个阶段中每个节点决定是放弃还是提交一旦参与者决定提交事务那么就不允许放弃事务。也就是说在一个节点决定提交事务之前它必须保证能够执行事务操作即使出现故障或者中途被替换掉。 在第二个阶段中事务的每个参与节点执行最终统一的决定提交或者放弃事务。这个约定实现了ACID中的原子性。 二阶段提交协议最早时用来实现数据库的分布式事务的不过现在常用的协议是XA协议该协议是基于二阶段提交协议提出的。不管是原始的二阶段提交协议还是XA协议都存在一些问题
在提交请求阶段需要预留资源在资源预留期间其他人不能操作。。数据库是独立的系统。数据库是独立的也就是说数据库是独立的第三方软件我们可以编程或修改业务代码但很少会修改数据库核心代码更不会根据业务需求修改实现不同的数据库代码逻辑。 个人感觉2pc依赖每个数据库节点的事务。 TCCTry-Confirm-Cancel
TCC 是Try预留、Confirm确认、Cancel撤销3个操作的简称它包含了预留、确认或撤销这2个阶段。
第一阶段为预留阶段。客户端通知节点A、节点B、节点C让它们预留执行操作X的相关资源客户端实现确认操作执行操作X和撤销操作取消执行操作X。然后客户端收到节点A、节点B、节点C的预留答复假设这里都是OK。 如果预留阶段的执行都没有问题就进入确认阶段。客户端执行确认操作通知节点A、节点B、节点C执行操作客户端收到确认操作的响应后完成分布式事务。 如果预留阶段出错比如节点A无法执行操作X那么就进入撤销阶段。客户端执行撤销操作通知节点A、节点B、节点C取消执行操作X客户端收到撤销操作的响应。 TCC本质上是补偿事务它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作也就是撤销操作。它是一个业务层面的协议可以将TCC理解为编程模型即TCC的三个操作都是在业务代码中编程实现的。为了实现一致性确认操作和补偿操作必须是幂等的。这两个操作会失败重试。 TCC不依赖于数据库的事务2pc应该是要依赖的而是在业务中实现了分布式事务这能减轻数据库的压力但对业务代码的入侵性比较高实现比较复杂。 ps我感觉这点是与2pc不同的点吧还有2pc是有一个节点作为协调者而TCC是由客户端作为协调者。 小结
二阶段提交协议和TCC是实现分布式系统ACID特性的方法
二阶段提交协议不仅仅是协议也是一种非常经典的思想。二阶段提交在达成提交操作共识的算法中应用广泛比如 XA 协议、TCC、Paxos、Raft 等。幂等性是指同一操作对同一系统的任意多次执行所产生的影响均与一次执行的影响相同不会因为多次执行而产生副作用。常见的实现方法有 Token、索引等。它的本质是通过唯一标识标记同一操作的方式来消除多次执行的副作用。 可以将 ACID 特性理解为 CAP 中一致性的边界最强的一致性。根据 CAP 理论如果在分布式系统中实现了一致性可用性必然受到影响。比如如果出现一个节点故障则整个分布式事务的执行都是失败的。实际上绝大部分场景对一致性要求没那么高短暂的不一致是能接受的另外也基于可用性和并发性能的考虑在开发实现分布式系统如果不是必须尽量不要实现事务可以考虑采用最终一致性。 BASE理论
BASE 理论是 CAP 理论中的 AP 的延伸是对互联网大规模分布式系统的实践总结强调可用性。
BASE理论的核心是基本可用Basically Available和最终一致性Eventually consistent。还有一种过度状态—软状态Soft state软状态描述的是实现服务可用性的时候系统数据的一种过度状态也就是说不通节点间数据副本存在短暂的不一致。
实现可用的4种方式
流量削峰例如12306订票系统可以在不同的时间出售不同区域的票将访问请求错开消弱请求峰值。延迟响应将购票请求在队列中进行排队过段时间在进行处理。体验降级如使用小图片代替原始图片通过降低图片的清晰度和大小提升系统的处理能力。过载保护把接收到的请求放在指定的队列中排队处理如果请求等待时间超时了假设是 100ms这个时候直接拒绝超时请求再比如队列满了之后就清除队列中一定数量的排队请求保护系统不过载实现系统的基本可用。
最终一致性
最终一致性是说系统中所有的数据副本在经过一段时间的同步之后最终能够达到一个一致的状态。在数据一致性上存在一个短暂的延迟。
那么如何实现最终一致性? 首先确定它以什么为准因为这是实现最终一致性的关键。一般来说工程实践中有如下几种方式
以最新写入的数据为准比如 AP 模型的 KV 存储采用的就是这种方式就是最新的数据以第一次写入的数据为准如果你不希望存储的数据被更改可以以它为准就是一次写入后面不会修改了。
常见的实现最终一致性的具体方式如下
读时修复在读取数据时检测数据的不一致进行修复。比如 Cassandra 的 Read Repair 实现具体来说在向 Cassandra 系统查询数据的时候如果检测到不同节点的副本数据不一致系统就自动修复数据。写时修复在写入数据检测数据的不一致时进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说Cassandra 集群的节点之间远程写数据的时候如果写失败就将数据缓存下来然后定时重传修复数据的不一致性。异步修复这个是最常用的方式通过定时检测副本数据的一致性并修复反熵的方式。 写修复就是写的时候没有成功就将数据缓存下来然后定时重传保证数据写入成功。写修复不需要做数据一致性对比性能消耗比较低对系统运行影响不大。而读修复和异步修复需要做数据的一致性对比性能消耗比较多。因此推荐写修复实现最终一致性。 小结
BASE 理论是对 CAP 中一致性和可用性权衡的结果它来源于对大规模互联网分布式系统实践的总结是基于 CAP 定理逐步演化而来的。它的核心思想是如果不是必须的话不推荐实现事务或强一致性鼓励可用性和性能优先根据业务的场景特点来实现非常弹性的基本可用以及实现数据的最终一致性。BASE 理论主张通过牺牲部分功能的可用性实现整体的基本可用也就是说通过服务降级的方式努力保障极端情况下的系统可用性。ACID 理论是传统数据库常用的设计理念追求强一致性模型。BASE 理论支持的是大型分布式系统通过牺牲强一致性获得高可用性。BASE 理论在很大程度上解决了事务型系统在性能、容错、可用性等方面痛点。另外我再多说一句BASE 理论在 NoSQL 中应用广泛是 NoSQL 系统设计的事实上的理论支撑。
参考
分布式协议与算法实战 学习笔记
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/911253.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!