「包在事务里了」和「短信已经发出去了」，中间隔着那个圈

上一篇的落点是：一条日志写到一半断电，剩下那半怎么补回来。 补它的办法，是把它和同一件事的另外几笔，当成一笔来记。

周二下午，群里先是一句： 「这块我包在一个事务里了，出错会回滚。」 晚上又补一句： 「昨天那个事务把订单表锁了二十分钟，全站都在排队。」

两句话说的是同一个东西的两面。

我们对「事务」的默认印象，是一个保护罩：进去之后出什么事，都能退回去。 这个印象在圈里成立，在圈外不成立。

数据库是那个专门记账、能按条件把记录查回来的软件。它把同类数据存在一张表里，一行就是一条记录。

事务是这个库里的一个圈。程序要做一件得分好几步才完成的事，先画一个圈，把这几步都圈进去。

全部写完了，宣布这个圈算数，这一步叫提交。 中途出事，宣布这个圈不算数，这一步叫回滚。

圈里的几笔，要么一起算，要么一起不算。它保证的就这一件事。

当天要定的事，落在这三问上。

一、这一圈里圈了哪几笔？它们都由数据库自己记吗？ 二、出错的时候，要退到哪一步？ 三、这个圈从画上到擦掉，要占多久？

三问的答案把处置分成三种：把圈缩小、让它能重来、把圈外那几笔做成事后补得回来的。

事务的形状，是两条命令中间夹着几条改数据的命令。

起手那条叫 BEGIN，意思是「从这里开始画圈」；收手那条叫 COMMIT，意思是「圈里这些算数了」。

PostgreSQL（一个常见的开源数据库）的文档写得很直白：BEGIN 和 COMMIT 把一串 SQL 命令围起来，于是它们成为一个事务。1

SQL 就是发给数据库的那种指令句子，比如「把这一行的状态改成已支付」。

同一页还写明这个圈保证了什么：几个步骤要么全做，要么全不做；从别人的角度看，这个事务要么完全发生，要么完全不发生。1

这里有个最容易漏掉的地方，也是「这条为什么回滚不了」最常见的答案。

不写 BEGIN 的话，每一条命令自己就是一个事务，执行完立刻提交。1

一条 UPDATE（改数据的那种命令）发出去，它不光开了圈，还顺手把圈擦掉了。后面再出错，这一条已经算数。

你会听到：「这条我单独发的。」「就一条 SQL，不用事务吧。」

问什么：它跟前面那几笔，在同一个圈里吗？

圈擦掉之前，别人看不见里面的改动。

文档写得很明确：事务做完之前，它已经做出的更新对其他事务不可见；做完的那一刻，所有更新一起可见。1

这对产品很实用：用户在页面上刷新，看不到一个「改了一半」的状态。

圈擦掉之后，也就没有「再退半步」这回事了。

要撤销，得趁圈还在，宣布它不算数，命令叫 ROLLBACK；它的作用范围是「这个事务到目前为止的所有更新」。1

「到目前为止」四个字有讲究：圈里还能再分小段。

在中间插一个保存点（SAVEPOINT），给这一段起个名字；后面出错，可以只回滚到这个保存点，之前的改动留着。1

这就是第二问的答案：退到哪一步，由你把圈分成几段决定。

你会听到：「我这儿打了保存点。」「回滚到下单之前那一步。」

问什么：这一退，退掉的是哪几笔？之前那几笔保住了吗？

圈里在改，圈外在读。两边的关系由隔离级别决定。

隔离级别这个名字听着抽象，它回答的是一句话：别人的圈擦掉之前，你能看见什么。2

PostgreSQL 的默认级别叫「读已提交」。

意思一句话说完：你只看得见别人已经提交的东西；别人写了还没提交，你看不见。2

这就挡掉了「读到别人写了一半的数据」，文档里管它叫脏读。2

读已提交之外还有一层：同一个圈里连着读两次，可能读到不一样的东西。

原因是别人在这两次之间提交了。文档的原话是：同一事务内两条连续的 SELECT（查数据的命令）可能看到不同的数据。2

所以事务给的是一段改动一起生效，它不负责把世界冻住。

有些业务确实要求读两次一样，比如做一份报表。数据库里有更严的级别：可重复读、可串行化。名字就是字面意思，代价是撞上冲突时事务会被退回去重来。2

你会听到：「我开的是可重复读。」「这个报表读到一半数据变了。」

问什么：这个圈里要读的东西，要求前后一致吗？

圈画上之后，圈里碰过的行就被占着。

占着的形式是锁。锁是数据库在那一行上留的一个记号：我改了还没收口，你先别动。3

锁有一个关键性质：一般要到事务结束才放。3

于是圈开多久，别人就等多久。文档里还有一句更狠的：只要没检测到死锁，等锁的事务会无限期等下去。3

群里那句「锁了二十分钟」，就是这么来的，也是第三问为什么重要。

还有一种锁出现在改表结构的时候，破坏力更大。

加一列、改字段类型这种命令，拿的是最强的那档表锁。文档写明：只有这档锁连普通查询都会被挡住。3

一条排在队里的改表命令，会把后面所有查询一起堵死。

还有一件慢性的账。

数据库改一行，不会把旧的那行立刻擦掉，它留一份旧版本；有个后台清道夫叫 VACUUM，负责回收这些旧版本。4

清道夫要等没有任何事务还看得见那份旧版本，才敢动手。4

所以一个开得很久的圈，会让表越撑越大。4

三个开关本来是管这件事的，默认值都是 0，也就是不设限：一条语句最多跑多久（statement_timeout）、等锁最多等多久（lock_timeout）、圈里空着最多空多久（idle_in_transaction_session_timeout）。5

第三个的说明直接写了理由：空闲的事务就算没拿重要的锁，也会挡住清理，久了让表变大。5

还有一种是大家都听过的结局：死锁。两个圈各自占着对方要的那一行，谁也走不下去。

MySQL 的 InnoDB（它的存储引擎）默认会检测这种情况，查出来之后回滚其中一个事务，被挑中的那个叫牺牲者。6

那份文档里还有一句值得抄给产品看：就算应用逻辑是对的，你也必须处理「这个事务要重来」。6

你会听到：「死锁了，重试一下就好了。」「这个事务里在等一个外部接口。」

问什么：这个圈最长会开多久？它等的是数据库，还是在等别的什么？

圈画得再大，也有圈不到的地方。

事务是数据库自己的一本账。它管得着的，只有通过它写进库里的那些改动。

发短信、调支付、写文件、往消息队列（一个先排着、等别人来取的地方）里丢一条，这些都发生在库外，回滚碰到它们，什么也撤不回来。

「款已经扣了，订单却回滚了」，就是这么来的。

换个顺序也帮不上忙：先发短信再提交，短信发出去之后提交失败；先提交再发短信，提交之后发短信失败。

两种顺序都留一个不完整的状态。

能做的，是让圈外那几笔变成事后补得回来的。

一种做法是让那一笔重发一次也不出事：第 7 期讲的幂等键就是这件事，同一件事发两次，结果跟发一次一样。

一种做法是记一笔待办：把「要发短信」这件事和订单写进同一个圈，再由一个后台慢慢去发。

还有一种是对账：每天拿库里的订单，跟支付那边对一遍，把差的那几笔挑出来。

这也解释了工程师那句「这个接口不能放进事务」。他通常是在说：这一步要等外部回话，放进圈里就是让锁一直开着。

你会听到：「这个操作要调第三方，我没包事务。」「先记一条消息，再异步发。」

问什么：圈外这一步失败了怎么补？补的时候会不会做第二遍？

听到「我包在事务里了」，先问一句圈外还有什么。答不上来，就把「回滚了」理解成「库里那几笔不算了」。

听到「那个事务锁了二十分钟」，先问它在等谁。等数据库还能查下去，等外部接口就得把这一步挪到圈外。

圈画得越小，退得越干净，占得越短。下一层是那一行：几千万行里，数据库怎么一下子就找到它要改的那条记录。