电商的账户系统负责记录和管理用户账户的余额,这个余额就是每个用户临时存在电商的前,来源可能是用户充值或者退货退款等多种途径。
从业务需求的角度分析,一个最小化的账户系统,它的数据模型可以用如下这张表表示:
这个表包括用户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 这两种隔离级别是常用的,它们的唯一区别是在进行的事务中,其他事务对数据的更新是否可见。