事务

在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴。 一、 什么是事务（Transaction） 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。事务具有如下四个属性，根据其首字母，我们一般将其称为事务的ACID四大属性： 原子性（Atomicity）： “原子”这个词的本义就是不可分割的意思

事务特性 原子性（Atomicity） 　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚， 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之 前和执行之后都必须处于一致性状态。 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不 能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 持久性（Durability） 　　 持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。 不考虑事务的隔离性，会发生的几种问题 不考虑事务的隔离性会发生以下情况： 　 　1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据 　　2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。 　　3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。 事务的隔离级别： 现在来看看 MySQL

存储过程：SET Transaction Isolation Level Read语法的四种情况 这几天一直在弄存储过程，现在在这里跟大伙共享下资料： SET Transaction Isolation Level Read UNCOMMITTED 使用这句东东呢可以分为四种情况，现在就在这里逐一介绍： 第一种情况： READ COMMITTED 这句的作用是： 指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是 SQL Server 的默认值。 第二种情况： READ UNCOMMITTED 这句的作用是： 执行脏读或0 级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。 第三种情况： REPEATABLE READ 这句的作用是： 锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别，所以应只在必要时才使用该选项。 第四种情况： SERIALIZABLE 这句的作用是： 在数据集上放置一个范围锁

转自： http://www.cnblogs.com/qanholas/archive/2012/01/04/2312152.html 存储过程：SET Transaction Isolation Level Read语法的四种情况 这几天一直在弄存储过程，现在在这里跟大伙共享下资料： SET Transaction Isolation Level Read UNCOMMITTED 使用这句东东呢可以分为四种情况，现在就在这里逐一介绍： 第一种情况： READ COMMITTED 这句的作用是： 指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是 SQL Server 的默认值。 第二种情况： READ UNCOMMITTED 这句的作用是： 执行脏读或0级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。 第三种情况： REPEATABLE READ 这句的作用是： 锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别

存储过程：SET Transaction Isolation Level Read语法的四种情况 这几天一直在弄存储过程，现在在这里跟大伙共享下资料： SET Transaction Isolation Level Read UNCOMMITTED 使用这句东东呢可以分为四种情况，现在就在这里逐一介绍： 第一种情况： READ COMMITTED 这句的作用是： 指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是 SQL Server 的默认值。 第二种情况： READ UNCOMMITTED 这句的作用是： 执行脏读或0级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。 第三种情况： REPEATABLE READ 这句的作用是： 锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别，所以应只在必要时才使用该选项。 第四种情况： SERIALIZABLE 这句的作用是： 在数据集上放置一个范围锁

AKF 扩展立方体 AKF 扩展立方体（AKF Scale Cube）是一个描述从单体应用到可扩展架构的模型，见 ( https://akfpartners.com/growth-blog/scale-cube )[ https://akfpartners.com/growth-blog/scale-cube ]。这个模型在 Scalability Rules （架构真经）一书中进行了描述。 AKF 扩展立方体把单体应用扩展到可扩展架构的方式的过程划分为3个正交维度： x 轴：水平复制 y 轴：业务拆分 z 轴：数据分片 这 3 个维度描述了从单体到可扩展架构的方法，在实践中有比较大的作用，x、y、z组合而成的向量大小正是系统的扩展性。 x 轴扩展 x 轴扩展描述了比较简单的扩展方式，又称水平扩展，通过复制节点，实现多个节点同时提供服务，从而大大提高系统的总体容量、解决单点问题等。 水平扩展是比较理想的扩展方式，一般来说开发难度不大，但增加部署复杂度。这种扩展最为典型的例子是数据库的主从复制和读写分离。 典型的 web 应用读写比例非常悬殊，通常是 10:1 、 100:1 甚至是 1000:1 ，因此需要更多的资源来支持读操作。同时，从数据的时效性上看，大部分数据并不需要非常高的实时性，3、5s 的少量的延迟往往是可被接受的。从数据的访问频率上看，基本上数据会遵守局部性法则

乐观锁 乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。 　实现方式1：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。 举例：假设莫某个商品是有库存才能下单，有库存的状态是1，没有库存状态变为2，用状态status表示。 下单操作包括3步骤： 1.查询出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根据商品信息生成订单 3.修改商品status为2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};

定义 当出现并发访问时，数据库需要合理地控制资源的访问规则，锁就是用来实现这些访问规则的 根据加锁的范围，Mysql里面的锁大致可以分成全局锁，表级锁和行锁三类。 全局锁 对整个数据库实例加锁，命令 Flush tables with read lock(FTWRL) ，在客户端断开时会自动释放，较安全。 当你需要让整个库处于只读状态时可以使用，之后其他线程的以下语句会被阻塞： 数据更新语句 ， 数据定义语句 ， 更新类事务的提交语句 。 典型使用场景是，全库逻辑备份。使用全局锁是为了保持数据一致性。 当 mysqldump 使用参数–single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。但是只有InnoDB支持。 表级锁 Mysql里面表级别的锁有两种：表锁和元数据锁（meta data lock，MDL）。 // 表锁语法： // 上锁 lock table 表名 read / write ; // 释放锁 // 与FTWRL类似，会在客户端断开时自动释放。 unlock tables ; 元数据锁 另一类表锁是MDL，不需要显示使用。在访问一个表的时候会被主动加上，保证读写的准确性。 比如A线程在遍历，B线程要改表结构，需要保证查询线程拿到的结果和表结构一致，这时候就不能让他改

Reference: [1] http://www.cnblogs.com/fjdingsd/p/5273008.html [2] http://blog.csdn.net/fg2006/article/details/6937413 数据库事务四大特性 如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下 四个特性 ： ⑴ 原子性（Atomicity） 　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 ⑵ 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 ⑶ 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束

隔离级别的定义： 　　事务指定一个隔离级别，该隔离级别定义一个事务必须与由其他事务进行的资源或数据更改相隔离的程度。隔离级别从允许的并发副作用（例如，脏读或幻读）的角度进行描述。 隔离级别的特性： ⑴ 原子性（Atomicity） 　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 ⑵ 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 ⑶ 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 　　关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。 ⑷