cap理论与分布式事务的解决方案

现在很火的微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP理论,即一个分布式系统要同时满足一致性(Consistency)、可用性(Availablility)和分区容错(Partition Tolerance)三个特性是一件不可能的事情。

CAP理论的简介

CAP理论是由Eric Brewer在2000年的PODC会议上提出的,该理论在两年后被证明成立。

CAP理论告诉架构师不要妄想设计出同时满足三者的系统,应该有所取舍,设计出适合业务的系统。

一致性(Consistency):一致性指的是数据的强一致性。每次的读操作都是读取的最新数据。即如果写入某个数据成功的话,之后的读取都应该读的是新写入的数据;如果写入失败的话,之后读取的都不应该是写入失败的数据。

可用性(Availability):可用性指的是服务的可用性。即每个请求都能在合理的时间内获得符合预期的响应结果。

分区容错性(Partition Tolerance):分区容错性指的是当节点之间的网络出现问题之后,系统仍然能够正常提供服务。

在分布式的系统中,P是基本要求,而单体应用则是CA系统。微服务系统通常是一个AP系统,即同时满足可用性和分区容错性。这样就有了一个在分布式系统中保证数据强一致性的难题,这个难题的一个解决方案就是分布式事务。

分布式事务的解决方案

在微服务系统中,每个服务都是独立的进程单元,每个服务都有自己的数据库。在通常情况下,只有关系型数据库在特定的数据引擎下才会支持事务(本地事务),而大多数非关系型数据库是不支持事务的,比如MongDB完全不支持事务,而Redis是支持事务的,虽然支持得不完整。

两阶段提交

网上购物在日常生活中是一个非常普通的场景,假设静静在某宝上购买了一个玩具,需要从静静的账户中扣除200块钱,同时玩具的库存数量需要减1,卖家的账户中增加200块钱。

如果这是一个单体应用,并且使用支持事务的数据库(比如InnoDB数据库引擎的MySQL、Oracle和SQL Server等),我们可能是这样写代码的:

@Transactional
public void update() throws RuntimeException{
    updateAccountTable(); // 更新账户表
    updateGoodsTable(); // 更新商品表
}

如果是微服务架构的话,账户是一个服务,商品是一个服务,两个独立的服务就不能使用数据库自带的事务了,因为这两个数据表可能并不在一个数据库中,这就需要用到两阶段提交的解决方案。

第一阶段,service-account发起一个分布式事务,交给事务式事务TC处理,事务协调器TC向所有参与事务的节点发送处理事务操作的准备操作。所有参与节点执行准备操作,将Undo和Redo信息写入日志中,并向事务管理器返回准备操作是否成功的消息。

第二阶段,事务管理器收集所有节点的准备操作是否都成功,如果都成功的话则通知所有的节点执行提交操作,如果有一个失败则执行回滚操作。

两阶段提交将事务分成了两个部分,大大提高了分布式事务的成功概率。然而,如果在第一阶段都成功了,而执行第二阶段的某一个节点失败,仍然会导致数据不准确。这种情况下一般需要人工去处理,这也是为什么要在第一步记录日志的原因。

另外,如果分布式事务涉及的节点很多,一旦某一个节点的网络出现异常,就会导致整个事务处于阻塞状态,大大降低数据库的性能。因此如果不是必要的话,建议是尽量少用分布式事务,有些时候过度设计反而会造成相反的效果。

三阶段提交

三阶段提交在两阶段提交的步骤中间加了一层预提交事务阶段。

1.CanCommit阶段。这个阶段和上面说的两阶段提交的准备阶段类似,不同的地方就是并没有进行诸如将Undo和Redo的信息写入事务日志的其他操作。

2.PreCommit阶段。这个阶段是一个缓冲,目的是推迟Commit的决定,只有保证所有参与者都知道了Commit的决定之后,才会真正发出Commit的决定。所有的参与者都会在这个阶段记录Undo和Redo的信息,并且当协调者发生故障之后,所有的参与者还能互相通信来确定事务是提交还是终止。

3.DoCommit阶段。这个阶段就是事务的真正提交,如果所有的参与者都向协调者发送了ACK响应,那么协调者就会完成事务,否则中断事务。

三阶段提交的方案引入了对参与者的超时机制,相比于两阶段提交只有协调者拥有超时的机制,三阶段提交解决了协调者突然挂掉引起的参与者一直阻塞的问题。

本质上来说,三阶段提交避免了状态停滞的问题。在两阶段提交的过程中有可能会因为各种原因产生状态停滞的问题,最明显的就是协调者突然宕机的情况。但是三阶段提交即使是协调者宕机也会让状态继续下去,参与者们也会互相通信确定事务是提交还是终止,从而使状态继续下去,哪怕状态是错的。

"在心碎中认清遗憾,生命漫长也短暂。"

原文地址:https://www.cnblogs.com/yanggb/p/11244250.html

时间: 2024-07-30 13:41:03

cap理论与分布式事务的解决方案的相关文章

分布式事务,EventBus 解决方案:CAP【中文文档】(转)

出处:http://www.cnblogs.com/savorboard/p/cap-document.html 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解,所以花了将近两周时间写了这份中文的CAP文档,对 CAP 还不知道的同学可以先看一下这篇文章. 本文档为 CAP 文献(Wiki),本文献同时提供中文和英文版本,英文版本目前还在翻译中,会放到Github Wiki 中. 目录 前言 1.Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick St

设计----【分布式事务】分布式事务和解决方案

一.前言 分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,特别是在微服务架构中,几乎可以说是无法避免,本文就分布式事务来简单聊一下. 二.数据库事务 在说分布式事务之前,我们先从数据库事务说起. 数据库事务可能大家都很熟悉,在开发过程中也会经常使用到.但是即使如此,可能对于一些细节问题,很多人仍然不清楚.比如很多人都知道数据库事务的几个特性:原子性(Atomicity ).一致性( Consistency ).隔离性或独立性( Isolation)和持久性(

分布式事务一致性解决方案分析

一.从数据一致性谈起 一致性问题,"万恶之源"是数据冗余和分布并通过网络交互+网络异常是常态. 1.数据一致性的情形 主库.从库和缓存数据一致性,相同数据冗余,关系数据库,为保证关据库的高可用和高性能,一般会采用主从(备)架构并引入缓存.其中数据不一致性存在于数据冗余的时间窗口内.常用的解决方案见数据库之架构. 多副本数据之间的数据一致性,相同数据副本,大数据领域,一份数据会有多个副本并存储到不同的节点上.客户端可以访问任何一个节点进行读写操作.常用的解决方案是基于Paxos.ZAB.

[转帖]分布式事务之解决方案(XA和2PC)

分布式事务之解决方案(XA和2PC) https://zhuanlan.zhihu.com/p/93459200 3. 分布式事务解决方案之2PC(两阶段提交) 针对不同的分布式场景业界常见的解决方案有2PC.TCC.可靠消息最终一致性.最大努力通知这几种. 3.1. 什么是2PC 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase).提交阶段(commit phase),2是指两阶段,P是指准备阶段,C是提交阶段.举例 :张三和李四好久不见,老友约起聚餐

分布式事务的解决方案

分布式事务是什么: 分布式事务是指事务的参与者.支持事务的服务器.资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上. 为什么会产生分布式事务: 当我们的单个数据库的性能产生瓶颈的时候,我们可能会对数据库进行分区,这里所说的分区指的是物理分区,分区之后可能不同的库就处于不同的服务器上了,这个时候单个数据库的ACID已经不能适应这种情况了,而在这种ACID的集群环境下,再想保证集群的ACID几乎是很难达到,或者即使能达到那么效率和性能会大幅下降,最为关键的是再很难扩展新的分区了,这个时

分布式事务,解决方案

聊聊分布式事务,再说说解决方案 分布式事务CAP理解论证-解决方案 分布式系统的2PC.3PC详细分析 github tcc示例 分布式事务.重复消费.顺序消费 一.理论 CAP相关: CAP与BASE相关:我的博客 而对于分布式中的问题的解决方案,CAP原则出现,描述如下: 一致性(Consistency): 像A节点写入一条信息之后,同一时刻,在其他节点都可以读到这条信息 可用性(Availability): 多布一些节点A,B,C-,任何时刻,用户访问,都应该以可预期的结果返回,而不是浏览

深入理解分布式事务,高并发下分布式事务的解决方案

这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现

分布式事务,高并发下分布式事务的解决方案

我在上一期介绍了spring的事务原理(详情见<深入理解spring事务原理>),Spring事务本质是单机下的事务,是由数据库本身保证的.今天,我将介绍一种比较复杂的事务:分布式事务. 1.什么是分布式事务 分布式事务就是指事务的参与者.支持事务的服务器.资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败.

分布式事务之解决方案(最大努力通知)

6.分布式事务解决方案之最大努力通知 6.1. 什么是最大努力通知 最大努力通知也是一种解决分布式事务的方案,下边是一个是充值的例子:交互流程 :1.账户系统调用充值系统接口2.充值系统完成支付处理向账户系统发起充值结果通知若通知失败,则充值系统按策略进行重复通知3.账户系统接收到充值结果通知修改充值状态4.账户系统未接收到通知会主动调用充值系统的接口查询充值结果通过上边的例子我们总结最大努力通知方案的目标 :目标 :发起通知方通过一定的机制最大努力将业务处理结果通知到接收方.具体包括 :1.有