事务的四个特性 (ACID) ，分别是原子性（ Atomicity), 一致性（ Consistency), 隔离性（ Isolation), 持久性（ Durability)。一致性是事务的目的，原子性，隔离性，持久性是一致性的必要条件。
十多年的碧江网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整碧江建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“碧江网站设计”,“碧江网站推广”以来，每个客户项目都认真落实执行。
隔离性：多个并发事务之间要相互隔离，对于两个并发的事务T1和T2，T1和T2的开始有先后顺序，这样每个事务都感觉不到有其他事务在并发地执行。
隔离级别有四种：
1、串行Serializable ：最严格的级别，事务串行执行，资源消耗最大。
2、可重复读REPEATABLE READ ：保证了事务T1不会修改事务T2未提交的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
3、读取已提交READ COMMITTED ：保证了事务T1不会读到事务T2未提交的数据，避免了“脏读取”。
4、读取未提交Read Uncommitted ：读取过程中会读取到非法数据。
脏读、幻读、不可重复读的区别：
脏读是T1读取了T2未提交的数据。
不可重复读则是读取了前一事务提交的数据，在某些情况下，不可重复读并不是问题，以最终查询的结果为准。
不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。
四种隔离级别与读取事务和写事务：
读取未提交，读不会阻塞任何事务，写只阻塞写，会导致读出现脏读、不可重复读、幻影读。
读取已提交，读不会阻塞任何事务，写阻塞读、写，因为写阻塞读，排除“脏读” 问题，但是读还是不阻塞写，不可重复读、幻影读会出现。
可重复读，读只阻塞写，写阻塞读、写，读阻塞写避免了“不可重复读”的问题，但是读事务并没有阻塞对数据库的插入操作，所以此 时“幻影读”问题照样存在。
Serializable 数据库系统会保证执行此种隔离级别事务的效果和顺序执行的效果一致。
默认的隔离级别：
MySQL：可重复读。
Oracle：只支持串行化和读已提交这两种级别，默认：读已提交。
并发控制：
在每个读的数据行上加上共享锁
此时我们一般采用READ COMMITTED的隔离级别，然后再结合以下几种并发控制的锁定策略：
* 乐观所 版本号重试
* 悲观锁 for update
* 乐观离线锁
* 悲观离线锁
事务常用的两个属性：readonly和timeout，设置事务的超时时间，防止大事务的发生。
平面事务模型：本地事务和JTA 事务。
事务管理涉及到的几个参与者：
1 资源管理器（ Resource Manager) ：资源管理器一般是数据库管理系统。
2 分布式事务协调者（ Distributed Transaction Coordinator,DTC)：此功能一般是由我们所用的 JavaEE 应用服务器实现，比如 jboss,websphere,weblogic 等。这个角色只有在 JTA 事务中才会存在。
3 事务管理器 (Transaction manager) ：每一个事务管理器都与相应的资源管理器所关联，它负责对分布式事务进行提交或者回滚。
4 应用程序（ Application)
以上四者的关系可以用以下的图形来形象的表述：
在日常的系统开发中，我们一般都会使用数据资源（比如数据库）来对系统的状态进行保存，那么我们根据系统涉及的数据资源的多少，将事务分为RESOURCE-LOCAL事务或者JTA全局分布式事务。
RESOURCE-LOCAL事务是指只有一个资源管理（RM) 的事务，事务操作都是对同一个数据库进行操作。
此时事务协调着和事务管理器的作用就有底层的资源管理器来实现了。比如目前我们在采用Spring来管理事务的时候，其实spring并没有事务功能，它仅仅是封装了底层数据库的事务操作而已。
国际上提出了一种分布式事务解决方案的标准OTS（Object Transaction Service），JavaEE 对OTS 做了实现，即JTS（Java Transaction Service ），java 又提供了操作JTS 的上层接口 JTA （Java Transaction API ）
全局事务是涉及多个资源管理器，此时需要引入事务协调者(可以理解为全局事务管理器，可基于可靠消息实现)来进行调节
通信协议：
1、应用服务器与事务管理器通过TX协议通信。
2、事务管理器与资源管理器通过XA协议通信。
3、事务管理器之间通过XA+（XA协议超集）协议通信。
提交过程：
两阶段提交协议2PC（two phase commit)
第一阶段：事务协调者发送“准备提交”消息给事务所涉及的所有的事务管理器，然后事务管理器又分送此消息给相应的资源管理器，然后事务管理器又将资源管理的响应情况告诉分布式事务协调着（DTC). 只有此阶段顺利完成后（既所有的资源管理器都同意提交事务），才会进入第二阶段。
第二阶段：当第一个阶段顺利完成后，事务协调者告诉事务管理器去提交事务
分布式最终一致性理论：
CAP理论：
C（一致性）在分布式环境下多个节点数据是否一致；
A（可用性）服务一直保持可用的状态；
P（分区容忍性）在分布式应用中，可能因为一些分布式的原因导致系统无法运转，好的分区容忍性，使应用虽然是一个分布式系统，但是好像一个可以正常运转的整体
BASE理论：
BA: Basic Availability 基本业务可用性；
S: Soft state 柔性状态；
E: Eventual consistency 最终一致性；