一、什么是事务？
1.1 业务和事务
业务可以理解为公司/领导/老师交给我们的任务，各种各样、花里胡哨。。。。
我们来举例几个场景
1.1.1 业务场景一
完成一个商品购买业务操作如下：
- 1）打开某宝、某东、搜索你要的商品，查询到某件商品，在此期间商品的浏览量等增加。
- 2）选择购买数量、下单。
- 3）跳出二维码页面，扫码，付款。
- 4）输入密码，完成下单，数据库中插入订单记录。此时用户可以查询到刚刚下的订单情况。
- 5）商家钱到账（假设没有中间物流操作）。
看似很完美？？殊不知其中会出现非常非常非常多的问题！
问题一：我查询到了某件商品，并且点击查看详情了，但是商品浏览量增加失败（商家很生气）。
问题二：我选择了购买数量，下单成功，但是数据库中并没有订单记录（插入失败），就导致我查询不到消费记录（我懵了）。
问题三：下单成功之后，我的钱扣了，商家的钱却迟迟不加（我和商家都很生气）
1.1.2 业务场景二
情人节到了，小刚为了表达对小美的爱意，打算给小美转账520元让他感动一番。
转账业务操作如下：
- 1）小刚打开支付宝转账功能，输入520，验证指纹OK（表面很开心，心里在滴血）。
- 2）支付宝扣小刚520元金额，并在消费记录表中，添加小刚的消费记录，最后发送短信提示小刚扣款成功。
- 3）支付宝在后台查询到小美，为他的余额增加520元。增加完成后，发送短信提醒小美。
- 4）小美手机接收到信息提示，小美赶紧查看支付宝余额，发现比原来多了520（么么哒）。
看完了场景一的问题之后，场景二会出现上面问题自己应该能想到了吧？？
还是我来给你细细道来~~
问题一：支付宝扣小刚520元成功，记录消费记录时失败，导致后面小刚一直查询不到这条消费记录（小刚打电话投诉客服）
问题二：支付宝扣小刚520元成功，最终调用发送短信代码失败，没有提醒小刚（导致小刚非常不满意此次消费）
问题三：上面的情况都还好，最怕的就是小美没有接到来自小刚转的520元（导致小美向小刚提出分手，小刚疯了）。
以上场景都属于业务，我们在做业务模块的功能时都能遇得到。
1.2 什么是事务
上面我们分析的业务操作多种多样，仅仅是有业务的概念是远远不够的（小刚都分手了！），因此为了保证业务操作的安全，避免"导致小刚分手"这样的悲剧发生，我们提出了事务的概念。
事务（Transaction）：如果一个业务操作中多次访问了数据库，必须保证每条SQL语句都执行成功。在一个事务中的所有操作，要么全部成功，要么全部失败。符合这个条件的业务，那就是事务。
即：事务中的任何操作，要么一起成功，要么一起失败。
- 完整的操作如下：
我的女朋友懂了，你们的呢？
二、事务的四大特性
一个完整的事务具备有四个特性，分别为原子性（Atomicity）、一致性（Consistency）、隔离性、持久性。
- 原子性（Atomicity）：事务是一个业务操作的最小单元，不可再分割，要么全部执行成功，要么全部执行失败。
小刚在转账时，如果其中有一个操作失败了，那么所有的操作必须全部回到小刚没有支付520元之前的状态。
- 一致性（Consistency）：事务执行前与执行后，数据库中数据应该保持相同的状态。
不管小刚给小美转了多少钱，小刚和小美加起来的钱永远是一样的。这就跟你不管去淘宝上买多少东西，你和马云加起来的钱总是一样的（前提是马云没有消费你的钱，但这是不可能的，小美也不可能不消费你的钱）。
- 隔离性（Isolation）：事务与事务之间不能互相影响，必须保持隔离性。
小刚最多同时只能给一个女生转账，不能给小美和小丽同时转账。
- 持久性（Durability）：如果事务执行成功，对数据库的操作是持久的。
假设上面的转账案例全部完成（小刚成功扣款，小美成功加钱），小刚再也要不回小美的那520元钱了（系统不会无缘无故扣小美520元，然后给你加520元）。