关于事务你真的知道吗？

写在前面

你们好我是啊晨 ，一个大数据分享者兼一个努力成为大垃圾的小垃圾
今天讲一些事务，面试什么还是挺多问的。
如有其它需要请阅读我的其它大数据文章，谢谢
中间有什么问题请评论留言。
要么忙着活，要么忙着死，请珍惜现在的时间：

事务

问：什么是事务呢？

答： 单个逻辑单元执行的一组操作，要么全成功，要不全失败

事务四大特性：（ACID）

问：事务的四大特性是什么呢？

答：原子性、一致性、隔离性、持久性。

原子性：（Atomicity）不可分割，事务操作要么都发生，要么都不发生

一致性：（Consistency）事务前后数据的完整性必须一致

隔离性：（Lsolation）是指多个用户并发访问数据库，彼此不被其他用户干扰，影响，要隔离

持久性：（Durability）一旦提交（commit），对数据库改变是永久性的。

分布式事务

问：嗯，事务回答的还可以，哪你知道分布式事务吗？

答：指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
分布式事务就是为了保证不同数据库的数据一致性。

常见的分布式事务解决方案

问：嗯，不错小伙子，那我再问你，常见的分布式事务解决方案，你知道哪些？

答：有基于XA协议的两阶段提交、消息事务+最终一致性、TCC编程模式

基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器

XA协议比较简单，成本也比较低 但是,性能不理想，无法满足高并发

消息事务+最终一致性

基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ（支持事务）就支持这一特性

用在高并发场景下

TCC编程模式

是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：
Try(尝试)、Confirm(确认)和Cancel(取消)三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。
总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

面试官：可以可以小伙子！！

总结一下吧

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。

作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力！

事务的并发问题

脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

不可重复读：事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致

幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

注：不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

MySQL 事务隔离级别

本篇完，记得关注点赞支持哈，谢谢观看鸭！！！

单是说不行，要紧的是做。——鲁迅