jsp网站开发的两种模式,怎么打广告吸引客户,营业推广策划方案,全国建设部官方网站转载自 分布式事务解决方案——柔性事务与服务模式
初识分布式系统
关于分布式一致性的探究
分布式系统的CAP理论#xff08;需要到博客中查看#xff09;
分布式系统的BASE理论#xff08;需要到博客中查看#xff09;
Java中的事务——JDBC事务和JTA事务
Java中的…转载自 分布式事务解决方案——柔性事务与服务模式
初识分布式系统
关于分布式一致性的探究
分布式系统的CAP理论需要到博客中查看
分布式系统的BASE理论需要到博客中查看
Java中的事务——JDBC事务和JTA事务
Java中的事务——全局事务与本地事务
关于分布式事务、两阶段提交协议、三阶提交协议
深入理解分布式系统的2PC和3PC
这里简单总结下以前几篇文章算是本文的背景知识。在分布式系统中存在CAP理论即可用性、数据一致性和分区容错性无法同时满足。所以一个基于CAP的最终一致性理论BASE理论是目前解决分布式问题比较靠谱的。
在分布式系统中是无法使用本地事务保证数据的一致性的。一种标准的分布式事务就是全局事务DTP模型。他是基于2PC来控制的。但是由于2PC自身就存在同步阻塞的问题这也就导致全局事务效率很低。所以这种全局事务并不适合解决大型网站的分布式事务问题。 柔性事务
在业内主要用来解决分布式事务的方案是使用柔性事务。所谓柔性事务相比较与数据库事务中的ACID这种刚性事务来说柔性事务保证的是“基本可用最终一致。”这其实就是基于BASE理论保证数据的最终一致性。
虽然柔性事务并不像刚性事务那样完全遵循ACID但是也是部分遵循ACID的简单看一下关于ACID四个属性柔性事务的支撑程度 原子性严格遵循 一致性事务完成后的一致性严格遵循事务中的一致性可适当放宽 隔离性并行事务间不可影响事务中间结果可见性允许安全放宽 持久性严格遵循 柔性事务的基础
前面介绍过了柔性事务的定义目前在业内关于柔性事务最主要的有以下三种类型异步确保型、补偿型、最大努力通知型。
这三种类型的柔性事务基本都有对应的实现不同的场景需要使用不同的柔性事务类型。而这几种柔性事务类型其实还是依赖一些基础模式的或者叫做基础接口基础功能。
比如要想使用可靠消息最终一致来实现异步确保型柔性事务就依赖接幂等操作和可查询操作。关于具体实现我们在后面的文章中介绍本文简单介绍下这些实现柔性事务依赖的基础模式。
注意下面要介绍的柔性事务的模式并不是柔性事务的方案。这些是做柔性事务的基础。也就是说如果你想做柔性事务你的接口和功能要满足下面的几个要求。不一定要都满足因为不同的方案的要求不一样。但是都不满足的话是不可能做柔性事务的。
可查询操作
可查询操作几乎是所有的分布式解决方案都需要的。
举一个常见的分布式场景的例子如订单处理这一功能
/** 支付订单处理 **/
public void completeOrder() {orderDao.update(); // 订单服务本地更新订单状态accountService.update(); // 调用资金账户服务给资金帐户加款pointService.update(); // 调用积分服务给积分帐户增加积分accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}以上这个支付订单处理的例子中除了订单服务本地更新订单状态以外的所有操作都需要调用RPC接口来执行这种情况单纯的本地事务就无法保证数据的一致性了。就需要引入分布式事务。在分布式事务执行过程中如果某一个步骤执行出错就需要明确的知道其他几个操作的处理情况这就需要其他的服务都能够提供查询接口保证可以通过查询来判断操作的处理情况。 为了保证操作的可查询需要对于每一个服务的每一次调用都有一个全局唯一的标识可以是业务单据号如订单号、也可以是系统分配的操作流水号如支付记录流水号。除此之外操作的时间信息也要有完整的记录。
幂等操作
幂等性其实是一个数学概念。幂等函数或幂等方法是指可以使用相同参数重复执行并能获得相同结果的函数如
f(f(x)) f(x)在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说同一个方法使用同样的参数调用多次产生的业务结果与调用一次产生的业务结果相同。 这一个要求其实也比较好理解因为要保证数据的最终一致性很多解决防范都会有很多重试的操作如果一个方法不保证幂等那么将无法被重试。
幂等操作的实现方式有多种如在系统中缓存所有的请求与处理结果、检测到重复操作后直接返回上一次的处理结果等。
可补偿操作
提到事务为了保证原子性就可能发生commit和rollback那么在分布式事务中要想进行rollback就需要提供可补偿操作。 比如上面的订单处理的例子中在调用积分服务给积分帐户增加积分操作执行之后经过分布式事务协调最终决定回滚整个事务那么就需要提供一个调用积分服务给积分帐户扣减积分的操作。
并且补偿操作同时也需要满足幂等性。
TCC操作
TCC 即 Try-Confirm-Cancel。 Try: 尝试执行业务
完成所有业务检查(一致性) 预留必须业务资源(准隔离性)
Confirm:确认执行业务
真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作要满足幂等性
Cancel: 取消执行业务
释放Try阶段预留的业务资源 Cancel操作要满足幂等性
这种类型和可补偿操作类似就是提供一种提交和回滚的机制。是一种典型的两阶段类型的操作。这里说的两阶段类型操作并不是指2PC他和2PC还是有区别的。
TCC与2PC协议比较
TCC位于业务服务层而非资源层
TCC没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力 • Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
TCC有较高开发成本 总结
本文主要是简单介绍了一下柔性事务和柔性事务实现的基础。柔性事务是目前主流的分布式事务解决方案其基础模式包含四个幂等操作、可补偿操作、可查询操作和TCC操作。后续文章会分别介绍关于分布式事务的解决方案敬请期待。
