当前位置: 首页 > 后端技术 > Java

我是怎么用CAP和BASE这两个基本理论杀其他队员的?

时间:2023-04-01 22:13:54 Java

本文内容编译自博学谷野建筑师CAP定理,又称布鲁尔定理,是美国加州大学计算机科学家布鲁尔于2000年提出的猜想。2002年,麻省理工学院的SethGilbert和NancyLynch发表了Brewer猜想的证明,使其成为分布式计算领域公认的定理。Brewer在提出CAP猜想时,并没有具体定义一致性这三个词的含义、可用性和分区容错性。不同材料的具体定义也不同。为了更好的解释,下面选择了RobertGreiner的文章《CAP Theorem》作为Referencebase。CAP理论的定义在分布式系统中(指相互连接并共享数据的节点集合),涉及到读写操作时,只有一致性(Consistence)、可用性(Availability)和分区容错性(Partition)公差)可以得到保证。三者中,另一者必须牺牲。Consistency、Availability和PartitionTolerance详细解释如下:C-ConsistencyConsistency读取保证返回给定客户端的最新写入。对于指定的客户端,读操作保证返回最新的写操作结果。这里不是强调同时拥有相同的数据。对于系统执行交易,在交易执行过程中,系统实际上是处于一种不一致的状态,不同节点的数据并不完全一致。一致性强调的是客户端的读操作可以获得最新的写操作结果,因为客户端事务执行过程中无法读取未提交的数据,客户端只能在事务提交后读取事务写入的数据,如果事务失败会回滚,客户端不会读取写入的数据交易的中间。A-可用性非故障节点将在合理的时间内(无错误或超时)返回合理的响应。这里强调的是合理响应,不超时,不报错。请注意,它没有说明“正确”的结果是什么,例如当它应该返回100时返回90,这绝对是一个不正确的结果,但可能是一个合理的结果。P-PartitionTolerance当网络分区发生时,系统将继续运行。当发生网络分区时,系统会继续“各司其职”。这里的网络分区是指:在分布式系统中,节点组成的网络应该是连通的。但是,由于某些故障(节点间网络连接断开、节点宕机),部分节点断开连接,整个网络被划分为若干区域,数据分散在这些断开连接的区域中。一致性、可用性和分区容忍度的选择虽然CAP的理论定义是三个要素中只能选择两个,但是当我们在分布式环境中思考时,我们会发现我们必须选择P(分区容忍度))元,因为网络本身不能做到100%可靠,可能会出现故障,所以分区是必然的现象。如果我们选择CA(一致性+可用性),放弃P(分区容忍度),那么当分区发生时,为了保证C(一致性),系统需要禁止写入。当有写请求时,系统返回错误(比如当前系统不允许写),这与A(availability)冲突,因为A(availability)要求不返回错误,不超时。因此,分布式系统理论上不可能选择CA(一致性+可用性)架构,而只能选择CP(一致性+分区容错)或AP(可用性+分区容错)架构,在一致性和可用性之间做出折衷选择。CP-Consistency+PartitionTolerance(一致性+分区容错)如上图所示,由于Node1和Node2之间的连接中断,造成了分区现象。Node1的数据已经更新到y,但是Node1和Node2之间的复制通道中断,数据y无法同步到Node2,Node2上的数据还是旧数据x。此时客户端C访问Node2时,Node2需要返回Error,提示客户端“现在系统发生错误”,这种处理方式违反了可用性(Availability)的要求,所以三个CAP只能满足CP。AP-Availability+PartitionTolerance(可用性+分区容忍度)也就是Node2节点上的数据或者旧数据x。此时,当客户端C访问Node2时,Node2将当前自己拥有的数据x返回给客户端,而实际上当前最新的数据已经是y,不满足一致性(Consistency)的要求,所以三个CAP只能满足AP。注:这里Node2节点返回x,虽然不是“正确”的结果,但是是“合理”的结果,因为x是旧数据,不是乱值,不是最新数据值得补充的是,CAP理论告诉我们,分布式系统只能选择AP或CP,但实际上并不是说整个系统只能选择AP或CP。对不同的应用场景和需求进行分类,每一类数据选择不同的策略(CP或AP),而不是直接将整个系统中的所有数据限制为同一个策略。另外,只能选择CP或AP,这意味着系统分区时不能同时保证C(一致性)和A(可用性),但不代表什么都不做。当分区故障解决后,系统仍然要维护保证ca。CAP理论的延伸——BASE理论BASE是指基本可用(BasicallyAvailable)、软状态(SoftState)、最终一致性(EventualConsistency)。其核心思想是即使无法实现强一致性(CAP一致性即强一致性),但应用程序可以通过合适的方式实现最终一致性。BA-BasicallyAvailable当分布式系统发生故障时,允许其失去部分可用性,即保证核心可用。这里的关键词是“部分”和“核心”。在实践中,哪些是核心需要根据具体的业务来权衡。例如,登录功能比注册功能更核心。不注册顶多影响部分用户的流失。如果用户已经注册但无法登录,则意味着用户无法使用系统,造成更广泛的影响。S-SoftState允许存在不影响系统整体可用性的系统中间状态。这里的中间状态是CAP理论中的数据不一致。E-EventualConsistency最终一致性系统中的所有数据副本,经过一定时间后,最终可以达到一致状态。这里的关键词是“某时”和“终于”,“某时”与数据的特性,不同业务、不同数据所能容忍的不一致时间是不同的。例如,支付服务要求秒级一致性,因为用户无时无刻不在关注;用户最新发布的微博可以容忍在30分钟内达到一致状态,因为用户在短时间内看不到名人发布的微博。.“final”的意思是无论花费多长时间,最终都会达到一致的状态。BASE理论本质上是对CAP的扩展和补充,更具体地说,是对CAP中AP方案的补充:CP理论忽略了延迟,但在实际应用中延迟是不可避免的。这意味着不存在完美的CP场景。即使有几毫秒的数据复制延迟,系统在几毫秒的时间间隔内也达不到CP要求。因此,CAP中的CP方案实际上是实现了最终一致性,只是“一定时间”指的是几毫秒。AP方案中一致性的牺牲只是指分区失败的那段时间,而不是永远放弃一致性。这实际上是BASE理论的延伸。分区时牺牲了一致性,但分区故障恢复后,系统应该达到最终一致性。数据一致性模型前面介绍的BASE模型提到了“强一致性”和“最终一致性”,下面分别介绍这些一致性模型。分布式系统通过复制数据来提高系统的可靠性和容错性,将数据的不同副本存储在不同的机器上。由于维护数据副本的一致性代价高昂,很多系统采用弱一致性来提高性能,下面介绍常见的一致性模型:强一致性要求无论对哪个数据副本进行更新操作,后续的所有读操作都必须能够获取最新数据。对于单副本数据,读写操作是对同一份数据进行的,容易保证强一致性。对于多副本数据,需要使用分布式事务协议。弱一致性在这种一致性下,用户通过一次操作读取系统特定数据的更新需要一段时间。我们称这段时间为“不一致窗口”。FinalConsistency是弱一致性的一种特例,在这种情况下系统保证用户最终能够通过一个操作读取到系统特定数据的更新(在读取操作之前没有其他数据的更新操作).“不一致窗口”的大小取决于交互延迟、系统的负载和数据的副本数。总结系统选择哪种一致性模型取决于应用对一致性的要求。选择的一致性模型也会影响系统如何处理用户请求和副本维护技术的选择。基于上面介绍的一致性模型,后面会介绍分布式事务的解决方案。灵活事务的概念灵活事务在电子商务等互联网场景下,传统事务暴露出数据库性能和处理能力的瓶颈。在分布式领域,基于CAP理论和BASE理论,有人提出了灵活事务的概念。基于BASE理论的设计思想,在灵活事务下,不影响系统整体可用性(BasicallyAvailable)),系统允许有一个数据不一致的中间状态(SoftState)。经过数据同步的延时之后,最终的数据才能达成共识。并不是完全放弃ACID,而是在保证系统吞吐量的情况下,通过放宽一致性要求,使用本地事务来实现最终的分布式事务一致性。实现灵活事务的一些特点以下是实现灵活事务的一些共同特点。这些特性不一定在具体的解决方案中得到满足,因为不同的解决方案有不同的要求。可见性(外部查询)在分布式事务的执行过程中,如果某个步骤失败,需要清楚地知道其他操作的处理状态。这就需要其他服务提供查询接口,保证Query能够确定操作的处理状态。为了保证操作能够被查询到,需要每个服务的每次调用都有一个全局唯一的标识,这可以是业务单据号(如订单号)或系统分配的操作流水号(如付款记录流水号)。此外,还应完整记录操作的时间信息。运算幂等性幂等性其实是一个数学概念。幂等函数或幂等方法是可以使用相同参数重复执行并获得相同结果的函数。幂等操作的特点是任意数量的执行都将与一次执行产生相同的影响。也就是说,同一个方法,使用同一个参数,多次调用产生的业务结果与调用一次产生的业务结果是一样的。之所以需要幂等性,是因为很多交易协议为了保证数据的最终一致性,都会有很多重试操作。如果方法不能保证幂等性,则不会重试。实现幂等操作的方式有很多,比如将所有的请求和处理结果缓存在系统中,检测到重复操作后直接返回之前的处理结果。本文由传智教育博学谷狂野建筑师教研团队发布。如果本文对您有帮助,请关注并点赞;有什么建议也可以留言或私信。您的支持是我坚持创作的动力。转载请注明出处!