电商：账户余额对不上账，事务来帮忙

电商的账户系统负责记录和管理用户账户的余额，这个余额就是每个用户临时存在电商的前，来源可能是用户充值或者退货退款等多种途径。

从业务需求的角度分析，一个最小化的账户系统，它的数据模型可以用如下这张表表示：

这个表包括用户ID、账户余额和更新时间三个字段。每次交易的时候，根据用户ID去更新这个账户的余额就可以了。

为什么总是对不上账

每个账户系统都不是孤立存在的，至少要和账户、订单、交易这些系统有着密切的关联。理想情况下，账户系统中的数据应该是自洽的。所有账户余额加起来，应该等于这个电商公司在银行专用账户的总余额。账户系统的数据也应该和其他系统的数据能够对得上。比如说，每个用户的余额应该能和交易系统中的充值记录，以及订单系统中的订单对得上。

不过，由于业务和系统的复杂性，现实情况下，很少有账户系统能够做到一点不差的对上每一笔账。所以，稍微大型一点的系统，都会有一个专门的对账系统，来核对、矫正账户系统和其他系统之间的数据差异。

对不上账的原因非常多，比如业务变化、认为修改了数据、系统之间数据交换失败等等。作为系统的设计者，我们只需要关注“如何避免由于技术原因导致的对不上账”就可以了，有哪些是因为技术原因导致的呢？比如说：网络请求错误、服务器宕机、系统Bug等。

“对不上账”是通俗的说法，它的本质问题是，冗余数据的一致性问题。

这里面的冗余数据并不是多余或者重复的数据，而是多份含有相同信息的数据。比如说，我们完全可以通过用户的每一笔充值交易数据、消费的订单数据，来计算出这个用户当前的账户余额是多少。也就是说，账户余额数据和这些账户相关的交易数据，都含有“账户余额”这个信息，那它们之间就互为冗余数据

在设计系统的存储时，原则上不应该存储冗数据，一是浪费存储空间，而是让这些冗余数据保持一致是一件非常麻烦的事情。但有些场景下存储冗余数据是必要的，比如用户账户的余额这个数据。

这个数据在交易过程中会被非常频繁地用到，总不能每次交易之前，先通过所有历史交易记录计算一下当前账户的余额，这样做速度太慢了，性能满足不了交易的需求。所以账户系统保存了每个用户的账户余额，这实际上是一种用存储空间换计算时间的设计。

如果说只是满足功能需求，账户系统只记录余额，每次交易的时候更新账户余额就足够了。但是这样做还有一个问题，如果账户余额被篡改，是没有办法追查的，所以在基类余额的同时，还需要记录每一笔交易记录，也就是账户的流水。流水的数据模型至少需要包含：流水ID、交易金额、交易时间戳以及交易双方的系统、账户、交易单号等信息。

虽然说，流水和余额也是互为冗余数据，但是记录流水，可以有效的修正由于系统bug或者人为篡改导致的账户余额错误等问题，也便于账户系统与其他外部系统进行对账，所以账户系统记录流水是非常必要的。

在设计账户流水时，有几个重要的原则必须遵守，最好是用技术手段加以限制：

• 流水记录只能新增，一旦记录成功不运行修改和删除。即使是由于正当原因需要取消一笔已经完成的流水，也不应该删除交易流水。正确的做法是再记录一笔“取消交易”的流水
• 流水号必须是递增的，我们需要用流水号来确定交易的先后顺序。

在对账的时候，一旦出现了流水和余额的不一致，并且无法通过业务手段来确定到底是哪里记错了的情况，一般的处理原则是以交易流水为准来修正余额数据，这样才能保证后继的交易能“对上账”

那从技术上，如何保证账户系统中流水和余额数据一致呢？

使用数据库事务来保证数据一致性

在设计对外提供的服务接口时，不能提供单独更新余额或者流水的功能，只提供交易功能。我们需要在实现交易功能的时候，同时记录流水并修改余额，并且要尽可能保证，在任何情况下，记录流水和修改余额这两个操作，要么都成功，要么都失败。不能有任何一笔交易出现，记录了流水但余额没更新，或者更新了余额但是没记录流水。

这个事儿说起来挺简单，但实际上是非常难实现的。毕竟应用程序只能先后来执行两个操作，执行过程中，可能会发生网络错误、系统宕机等各种异常的情况，所以对于应用程序来说，很难保证这两个操作都成功或者都失败。

数据库提供了事务机制来解决这个问题，实际上事务这个特性最初就是被设计用来解决交易问题的，在英文中，事务和交易就是同一个单词：Transaction。

我们先看一下如何来使用 MySQL 的事务，实现一笔交易。比如说，在事务中执行一个充值 100 元的交易，先记录一条交易流水，流水号是 888，然后把账户余额从 100 元更新到200 元。对应的 SQL 是这样的：

mysql> begin; -- 开始事务
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account_log ...; -- 写入交易流水
Query OK, 1 rows affected (0.01 sec)
mysql> update account_balance ...; -- 更新账户余额
Query OK, 1 rows affected (0.00 sec)
mysql> commit; # 提交事务
Query OK, 0 rows affected (0.01 sec)

我们来看一下，事务可以给我们提供什么样的保证？

• 首先，它可以保证，记录流水和更新余额这两个操作，要么都成功，要么都失败，即使是在数据库宕机、应用程序退出等等这些异常情况下，也不会出现，只更新了一个表而另一个表没更新的情况。这是事务的原子性（Atomic）。
• 事务还可以保证，数据库中的数据总是从一个一致性状态（888 流水不存在，余额是 100元）转换到另外一个一致性状态（888 流水存在，余额是 200 元）。对于其他事务来说，不存在任何中间状态（888 流水存在，但余额是 100 元）。
  其他事务，在任何一个时刻，如果它读到的流水中没有 888 这条流水记录，它读出来的余额一定是 100 元，这是交易前的状态。如果它能读到 888 这条流水记录，它读出来的余额一定是 200 元，这是交易之后的状态。也就是说，事务保证我们读到的数据（交易和流水）总是一致的，这是事务的**一致性 **(Consistency)。
• 事实上，这个事务的执行过程无论多块，它都是需要时间的，那修改流水表和余额表对应的数据，也会有先后，那一定存在一个时刻，流水更新了，但是余额还没有更新，也就是说每个事务的中间状态是事实存在的
  数据库为了实现一致性，必须保证每个事务在执行过程中，中间状态对其他事务不可见。比如说我们在事务 A 中，写入了 888 这条流水，但是还没有提交事务，那在其他事务中，都不应该读到 888 这条流水记录。这是事务的隔离性
• 最后，只要事务提交成功，数据一定会被持久化到磁盘中，后继即使发生数据库宕机，也不会改变事务的结果，这就是事务的持久性

理解事务的隔离级别

有了数据库的事务机制，只要确保每一笔交易都在事务中执行，我们的账户系统就很容易保证流水和余额数据的一致性。但是，ACID是一个非常严格的定义，或者说是理想的请。如果想要完全满足ACID，一个数据库的所有事务和SQL都只能串行执行，这个性能肯定是不能满足需求的。

对于交易系统来说，事务的原子性和隔离性是必须要保证的，否则就失去了使用事务的意义了，而一致性和隔离性可以适当牺牲，来换取性能。所以，MySQL提供了四种隔离级别：

这个表里面自上到下，一共有四种隔离级别：RU、RC、RR 和 SERIALIZABLE，这四种级别的隔离性越来越严格，性能也越来越差，在 MySQL 中默认的隔离级别是 RR，可重复读。

• RU级别，完全不隔离。每个进行事务的中间状态，对其他事务都是可见的，所以有可能出现“脏读”，脏读对应用程序来说比较难处理，所以基本不用。
• 第四种“序列化”级别，具备完美的“隔离性”和“一致性”，性能最差，也很少会用到。
• 常用的级别是RC和RR，MySQL默认使用RR。这两种隔离级别都可以避免脏读，能够保证在其他事务中不会读到未提交事务的数据，换句话说，只要你的事务没有提交，那这个事务对数据做出的更新，对其他会话是不可见的，它们读到的还是你这个事务更新之前的数据。
• RC 和 RR 唯一的区别在于“是否可重复读”：
  • 在一个事务执行过程中，它能不能读到其他已提交事务对数据的更新，如果能读到数据变化，就是“不可重复读”，否则就是“可重复读”。
  • 在同一个事务内两次同一条数据，读到的结果可能不一样，这就是“不可重复读”
  • 在 RR 隔离级别下，在一个事务进行过程中，对于同一条数据，每次读到的结果总是相同的，无论其他会话是否已经更新了这条数据，这就是“可重复读”。

理解了这几种隔离级别，最后我们给出一种兼顾并发、性能和数据一致性的交易实现。这个实现在隔离级别为 RC 和 RR 时，都是安全的。

• 我们给账户余额表增加一个 log_id 属性，记录最后一笔交易的流水号。
• 首先开启事务，查询并记录当前账户的余额和最后一笔交易的流水号。
• 然后写入流水记录。
• 再更新账户余额，需要在更新语句的 WHERE 条件中限定，只有流水号等于之前查询出的流水号时才更新。
• 然后检查更新余额的返回值，如果更新成功就提交事务，否则回滚事务。

需要特别注意的一点是，更新账户余额后，不能只检查更新语句是不是执行成功了，还需要检查返回值中变更的行数是不是等于 1。因为即使流水号不相等，余额没有更新，这条更新语句的执行结果仍然是成功的，只是更新了 0 条记录。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> -- 查询当前账户的余额和最后一笔交易的流水号。
mysql> select balance, log_id from account_balance where user_id = 0;
+---------+--------+
| balance | log_id |
+---------+--------+
| 100 | 3 |
+---------+--------+
1 row in set (0.00 sec)
mysql> -- 插入流水记录。
mysql> insert into account_log values
-> (NULL, 100, NOW(), 1, 1001, NULL, 0, NULL, 0, 0);
Query OK, 1 row affected (0.01 sec)
mysql> -- 更新余额，注意where条件中，限定了只有流水号等于之前查询出的流水号3时才更新。
mysql> update account_balance
-> set balance = balance + 100, log_id = LAST_INSERT_ID(), timestamp = NOW
-> where user_id = 0 and log_id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> -- 这里需要检查更新结果，只有更新余额成功（Changed: 1）才提交事务，否则回滚事务。
mysql> commit;
Query OK, 0 rows affected (0.01 sec)

小结

• 账户系统用于记录每个用户的余额，为了保证数据的可追溯性，还需要记录账户流水。流水记录只能新增，任何情况下都不允许修改和删除，每次交易的时候需要把流水和余额放在同一个事务中一起更新。
• 事务具备原子性、一致性、隔离性和持久性四种基本特性，也就是 ACID，它可以保证在一个事务中执行的数据更新，要么都成功，要么都失败。并且在事务执行过程中，中间状态的数据对其他事务是不可见的。
• ACID 是一种理想情况，特别是要完美地实现 CI，会导致数据库性能严重下降，所以
  MySQL 提供的四种可选的隔离级别，牺牲一定的隔离性和一致性，用于换取高性能这四种隔离级别中，只有 RC 和 RR 这两种隔离级别是常用的，它们的唯一区别是在进行的事务中，其他事务对数据的更新是否可见。