spring事务概念介绍

事务的基本概念

事务是访问并可能更新数据库中各种数据项的一个程序执行单员

事务的四个属性ACID
原子性(Automicity)：事务中的诸多操作，要么都做，要么都不做
一致性(Consistency): 事务必须使数据库从一个一致性状态到另一个一致性状态
隔离性(lsolation):一个事务的执行不能被其他事务干扰，一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰
持久性(Durability):一个事务一旦提交，数据库中数据的改变应该是永久性的

事务的基本原理

spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的，对于纯JDBC操作数据库

1.获取连接connection con=DriverManager.getConnection()
2.开启事务con.setAutoCommit(true/false)
3.执行CRUD操作
4.提交事务/回滚事务 con.commit()/con.rollback()
5.关闭连接
spring不需要2，4，spring如何开启事务和关闭事务
在配置文件中开启注解驱动，在相关的类和方法上通过注解@Transactional标识

spring事务的传播属性

事务传播 - Propagation
REQUIRED:
使用当前的事务，如果当前没有事务，则自己新建一个事务，子方法是必须运行在一个事务中的；如果当前存在事务，则加入这个事务，成为一个整体。
举例：领导没饭吃，我有钱，我会自己买了自己吃；领导有的吃，会分给你一起吃。
SUPPORTS:
如果当前有事务，则使用事务；如果当前没有事务，则不使用事务。
举例：领导没饭吃，我也没饭吃；领导有饭吃，我也有饭吃。
MANDATORY:
该传播属性强制必须存在一个事务，如果不存在，则抛出异常
举例：领导必须管饭，不管饭没饭吃，我就不乐意了，就不干了（抛出异常）
REQUIRES_NEW:
如果当前有事务，则挂起该事务，并且自己创建一个新的事务给自己使用；如果当前没有事务，则同 REQUIRED
举例：领导有饭吃，我偏不要，我自己买了自己吃
NOT_SUPPORTED:
如果当前有事务，则把事务挂起，自己不适用事务去运行数据库操作
举例：领导有饭吃，分一点给你，我太忙了，放一边，我不吃
NEVER:
如果当前有事务存在，则抛出异常
举例：领导有饭给你吃，我不想吃，我热爱工作，我抛出异常
NESTED:
如果当前有事务，则开启子事务（嵌套事务），嵌套事务是独立提交或者回滚；如果当前没有事务，则同 REQUIRED。但是如果主事务提交，则会携带子事务一起提交。如果主事务回滚，则子事务会一起回滚。相反，子事务异常，则父事务可以回滚或不回滚。
举例：领导决策不对，老板怪罪，领导带着小弟一同受罪。小弟出了差错，领导可以推卸责任。

数据库事务隔离级别

read-uncommitted 导致脏读
read-committed 避免脏读，允许不可重复读和幻读
repeatable-read 避免脏读，不可重复读，允许幻读
serializable 串行化读，事务只能一个一个执行，避免脏，不可重复 幻，执行速度慢
脏读：一个事务对数据进行了增/删/改，但未提交，另一个事务可以读取到未提交的数据。如果第一个事务这时候回滚了，那么第二个事务就读到了脏数据

不可重复读;一个事务中发生了两次读操作，在第一次读和第二次读之间，另外一个事务对数据进行了修改，这时候两次读取的数据是不一致的

幻读：第一个事务对一定范围的数据进行了批量修改，第二个事务在这个范围内增加了一条数据，这时候第一个事务就会丢失对新增数据的修改

spring中的事务隔离级别

isolation-default 这是platformTransactionManager默认的事务隔离级别，使用数据库默认的事务隔离级别/另外4个与JDBC的事务隔离级别相对应
isolation-read_uncommitted
isolation-read_committed
isolation-repeatable-read
isolation-serializable

CAP理论

一致性(Consistency)
可用性(Avalilability)
分区容错性(Partition Tolerance)

分区容错性：一个分布式系统里面，节点组成的网络本来应该是连通的，然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

1.分布式系统的特性

CAP理论告诉我们，在分布式系统中，最多实现两点，网络肯定会延迟，丢包，因此分区容错性必须实现，只能在可用性和一致性之间权衡，为了可用性，一般将强一致性转换成最终一致性

2.数据的一致性

强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的值
弱一致性：在系统写入成功之后，系统不承诺立即可以读到最新写入的值，也不会承诺多久之后可以读到
最终一致性：系统保证在没有后续更新的前提下，最终返回上一次更新的值，不一致窗口的时间受通信延迟，系统负载，和副本的个数影响