网站模板紫色,廊坊网站推广的公司,深圳哪些公司需要做网站,wordpress 512很多同学在开发中已经不自觉的接触了很多事务相关的代码#xff08;尤其是在数据库操作中#xff09;#xff0c;但是事务究竟是做什么的#xff0c;有没有必要必须这么操作#xff1f; 一段典型的代码如下#xff1a; db.beginTransaction();
try {// do some CRUD oper… 很多同学在开发中已经不自觉的接触了很多事务相关的代码尤其是在数据库操作中但是事务究竟是做什么的有没有必要必须这么操作 一段典型的代码如下 db.beginTransaction();
try {// do some CRUD operationdb.commit();
} catch {//Error in between database transaction db.rollback(); } finally { db.endTransaction(); } 从这段代码可以更直观的感受一下 “事务” 这个抽象的概念那么事务是干什么用的呢 事务Transaction 在wiki的解释中事务是一组单元化的操作这组操作可以保证要么全部成功要么全部失败只要有一个失败的操作就会把其他已经成功的操作回滚。这样的解释还是不够直观看下面一个经典的例子。 假设有两个银行账户A和B现在A要给B转10块钱也就是转账。在银行系统中A和B是两个独立的账户所以转账操作会被分解 从A的账户中扣掉10块钱在B的账户中添加10块钱那么问题就来了如果成功的在A账户中扣掉了钱但是没有在B中加钱怎么办或者A中没有成功扣款B中却加了钱怎么办这些可能性都是有的比如突然断电、系统崩溃或者A账户本来就没有钱。所以无论上面哪一张情况发生都是不应该的。 解决上面问题的一种简单方法就是事务 - 要么两个操作都成功返回一个成功的结果否则把所有操作回滚返回一个失败的结果。所谓回滚就是如果从A中扣钱成功但B中加钱失败的话那么把A中扣得钱再还回去。 注事务的英文Transaction其实就是交易的意思 事务操作的基本步骤概括如下 开始事务执行一系列的数据库操作如果没有错误发生那么提交事务返回成功如果有错误发生那么回滚事务返回失败同时事务发展出几个基本原则 - ACID Atomicity 原子性要不成功要么失败部分成功是不可以的Consistency 一致性在事务开始之前和事务结束以后数据库的完整性没有被破坏一致性一般是由应用来指定的Isolation 隔离性当一个事务正在进行的时候假设没有第二个事务在进行并发如果真的发生了系统需要保证隔离的程度Durability 持久性事务完成后该事务对数据库所作的更改便持久地保存在数据库之中防止系统崩溃这几个原则构成了单一数据源事务的基本原则。 代码实现 由于事务的这些特点所以在事务相关的代码中基本都是类似的风格 db.beginTransaction();
try {// do some CRUD operationdb.commit();
} catch {//Error in between database transaction db.rollback(); } finally { db.endTransaction(); } 这就是我们经常见到的代码无论哪种语言。这种相对比较固定的模板导致一种“声明式”事务的产生在Spring中会经常见到所谓的“声明式”大概表现如下 Transactional
public void insertXXX() { // do something... } 在方法的声明上通过 Transactional 注解把一个方法标注为支持事务的那么在执行的时候容器会自动给这个方法围绕上面的代码块。 事务的实现原理 在开始的时候我们说事务可以保证操作的ACID原则那么事务究竟是如何保证这些原则的db.beginTransaction() 、db.commit()、db.rollback()和db.endTransaction()究竟干了什么事如果这些操作本身也失败了怎么办 实现事务功能的系统通常叫 “TransactionProcessingMonitor” 或 “TransactionManager”这些系统通常会被打包进数据库引擎中在分布式系统中也会作为一个独立的模块存在。 解决ACID问题的两大技术点是 预写日志Write-ahead logging 保证原子性和持久性锁locking 保证各隔离性这里并没有提到一致性这是因为一致性是应用相关的话题它的定义一般由业务系统来定义 - 什么样的状态才是一致的而实现一致性的代码通常在业务层逻辑的代码中得以体现。 锁 是大家熟悉的一个话题在并发环境中通过读写锁来保证操作的互斥性没有太多神奇的东西。根据隔离程度不同锁的运用也不同可能会产生一些问题具体可以查看 Isolation (database systems)。 本文比较感兴趣的是预写日志。因为在数据库的复杂数据结构中更新数据是一个比较慢的操作保证这种操作的原子性和持久性是很困难的。预写日志的工作模式是这样的在任何事务操作发生之前先把所有的变化写入一个日志文件并持久化然后再开始真实的写数据库操作。如果在接下来的操作中系统崩溃那么我们可以在系统恢复之后检查日志和数据库中的记录来决定是继续执行完成未尽的任务还是回滚操作 - 把数据库还原到这次事务之前的一个状态。 预写日志一般采用简单顺序日志(sequential file)的写入格式这样日志写入速度可以很快。这点很重要因为一般事务操作的吞吐量往往受到日志系统速度的限制。日志的格式会同时记录redo和undo的信息。 分布式事务 在大型应用开发中经常要做业务拆分把原来的单一架构的应用拆分成不同的服务。不同的服务之间松耦合可以很好的解决业务耦合问题但是这样也会带来事务处理的问题如果一个操作会同时写入两个数据库那么如何保证这两个写入的一致性 单一数据库可以通过ACID原则保证自己的事务处理但是如果有两个不同的数据库如何保证针对这两个数据库的事务都成功呢在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题。 简单来说J2EE的2PC协议是这样的先把事物请求发送给中间协调器协调器负责各个数据源的事物处理。处理过程分两个阶段 投票阶段 协调器把事物请求发送给各个数据源数据源负责各自的事物处理。完成阶段 协调器根据各个数据源的返回结果决定是处理成功或者失败只要有一个结果是失败的那么会回滚所有数据源的事物处理。这种处理方式实际上是一个放大版的ACID原则。但是在分布式环境下2PC 是反可伸缩模式在事务处理过程中参与者需要一直持有资源直到整个分布式事务结束。这样当业务规模达到千万级以上时2PC 的局限性就越来越明显系统可伸缩性会变得很差。 CAP 在过去Inktomi的Eric Brewer曾提出过分布式系统的一种猜想conjecture,在分布式系统中的三项重要指标 Consistency 一致性 Availability 可用性 Partition-tolerance 分区容忍度是不能同时成立的 - 在任意时刻只有两项能同时成立。对于高流量的网站来说为了提高系统伸缩性一般都会牺牲一致性。 BASE BASE是一种尝试通过牺牲一部分一致性而达到高可用性的原则ACID原则中要求系统的每个操作之后都是连续的但是BASE认为系统是可容忍局部的/短时间的不一致。 在基于ACID的事务中事务是简单可靠的为了达成这种效果往往会造成耗尽整个系统的资源造成整体不可用。而BASE的实现是复杂的和业务紧密相关的。BASE 原则体现在采用这种原则意味着放弃ACID 基本可用Basically Available软状态Soft state最终一致Eventually consistent这是一组非常抽象的概念通过这组原则你不能领会任何可行的具体的系统设计方案。BASE并没有指明任何方案只是在告诉你 - 其实还可以这么搞 下面看一下简单的例子(从这里偷来的)假如有一个系统可以在上面买卖物品可以设计着这样的表结构 user and transaction 在这个系统中如果产生了一项交易那么会现在Transaction表中记下一条记录然后在买家和卖家表中分别更新记录。基于ACID原则的事务代码是这样的 acid 这里面的三条SQL操作会分别更新三个不同的数据库在ACID系统中会使用2PC实现。如果从BASE的角度来考虑可以这么设计 base 对于整个系统来说Transaction表才是真正有意义的User表中的相关数据可以认为是为了系统性能而设计的缓存这样不必查Transaction表即可或许相关的数据。所以可以设计出上面这种事务模型这种模型的潜在问题是如果对于User表的操作失败了那么在用户端看到的结果是不准确的。现在我们的系统已经出现了不一致的问题如果我们提前告知用户他看到的数据是粗略的估计那么这个问题在业务上算是解决了。 但是如果我们不能容忍这种可能会造成永久的不一致那么该如何解决问题呢答案在消息系统 - 可靠的消息系统。下面是改进版 base and mq 在这种设计中第一段代码保证了Transaction和消息持久化的事务性然后在消息处理系统中在分别更新User表的数据。并且在处理消息的时候仅在事务成功的时候才移除消息这样可以保证User可以成功的更新。因为用到了消息系统所以必然存在消息的延迟问题而这正式前面说的 - 牺牲一部分的一致性User和Transaction表不是同步更新的。但是一旦消息被成功处理我们最终会达成一致的状态 - 即最终一致。 看完了这个例子对于BASE也仅仅是初步的认识在真实的业务系统中还需要根据自己业务的特色设计相应的解决方案。 注1分布式事务确实牛逼写作过程中深感压力如果不足不对的地方还请高手多多指正。 注2对于最开始那个转账的例子用BASE思想的实现现在还不方便说因为这是蚂蚁内部的资料。 参考: ACIDTransaction Processing Cheat SheetDatabase transactionSpring事务配置的五种方式Transaction processing systemWrite-ahead logging牺牲一致性来换取分布式架构的可伸缩性可伸缩性最佳实践来自eBay的经验Base: An Acid Alternative 作者ntop链接https://www.jianshu.com/p/d322cba3add4转载于:https://www.cnblogs.com/miracle77hp/p/10170118.html
