事务，其实是一次交易，你听说过吗？

阅读全文，约 5 分钟

这是江帅帅的第028篇文章

到底什么是事务？我们先百度一下。

我相信，很多人都看懵逼了，包括工作了好几年的人，其实你也不能很清楚地讲明白到底事务是啥？可能，你会跟我举“账户 A 给 账户 B 转 100 块”案例，然后吧啦吧啦一堆，但这个案例，其实是有很大问题的。

那事务到底应该怎么去理解呢？很简单，它指的是【交易】，最早 Transaction 这个词，出现在金融领域。比如你去市场买菜，必须一手交钱一手交货，你试试不给钱，拎着菜就跑，看大妈会不会追你一路；另外是大妈收了你的钱，也必须要把菜给你。交易的过程，必须要保证交易的双赢。

其实，有个问题，事务跟数据库到底有啥关系？

很明显，事务并不是数据库发明的专有词汇，对吧？那为啥很多人一听到“事务”，就直接想到了数据库事务，然后又想到了数据库事务的 ACID 特性。这种普遍的思维，会给大家带来大量的麻烦，背后的原因，是大家一直秉持【数据 + 操作数据】来做开发的。可以看得出，是大家对数据库事务的依赖，甚至当作业务的一部分，还听说有人把代码写到数据库中，那可能就傻缺了，访问量一上来，数据库就直接爆了！

还有，比如在项目架构被拆分了、服务被拆分了、数据库被拆分了，可能你心里会想，那我的事务应该如何保证？又好比，在分布式系统中，采用了分布式事务，而它也是一个超级大坑，对性能伤害很大，所以有时候对架构师的挑战还是蛮大的。

抓紧时间弄清楚事务，最要紧！

当你进行交易时，买卖双方需要交换物品（信息）。开始交易，交易要么成功，双方都拿到自己想要的物品（信息）；交易要么失败，大家手上的东西没发生改变。继续拿买菜举例，如果你拿了菜而没给钱，或者大妈收了你的钱而不给你菜，这还是交易吗？不是了，对吧？这是有意外发生了！怎么办？可能会报警，让第三方的警察叔叔来处理。

好，这里引出了一个【第三方】的概念，那我套用一个常见的交易场景来说。比如，你在淘宝上买了东西并付款，钱会到支付宝，也就是第三方支付担保，然后店铺会通过快递给你邮寄商品过来，通过支付宝可以付款，通过快递可以收货，也能达成交易双赢。这过程中，如果交易有问题，比如你收不到货，支付宝会给你退钱。

上面都是日常中的交易场景，大家心里都会很清晰，我支付了钱，需要收到啥商品，有不同的状态需要跟踪并处理。然后，我们再来看看开发中的交易。

我们平时如何来处理交易的？两种方式：订单和日志。

我们可以通过订单来记录双方的具体状态，交易中过往的行为的记录数据，可以操作日志来实现。这就好像我们买东西的时候，脑袋里会一直去记住这件事，给了钱然后获取物品。那系统中的交易数据，如何来记录呢？那肯定是数据库。

数据库，其实就是做好本分，存储好东西就行。

当系统和数据库结合后，工作模式也像是交易，系统中把内部运行中的生命周期状态交换给数据库进行存储，这时需要确保系统的状态数据能得到可靠的存储、可靠的获取，那就需要有一定的机制来保障这个交易，也就是所谓的 Transaction，事务。平时大家看到的事务日志，其实就是数据库为了能达到数据交换的可靠性，常见的几个东西：Transaction Log、Transaction Journal、Binary Log 等。

通过交易来介绍事务，是不是清晰了很多？

公众号：江帅帅（ID：NXJSS666）

CSDN 博客：江帅帅

长按二维码关注

愿一个热爱技术的灵魂，给你带来更多惊喜文章。

  感谢你的阅读！