数据库中存储的都是一些具有业务价值的数据, 我们姑且称之为资源. 首先啊, 我们给这些资源简单的分个类:
- 消耗型资源: 这类资源具有量的概念, 会随着使用而减少, 比如说某个用户的账户余额.
- 非消耗型资源: 这类资源没有量的概念, 它的使用对其资源本身没有影响, 比如说某个用户的身份信息.
我们规定消耗型资源有且仅有以下操作:
- Read: 读取资源的当前状态;
- Consume: 消费资源, 可自由回滚;
- Produce: 生产资源, 根据实际业务可选择支持回滚.
非消耗型资源有且仅有以下操作:
- Read: 读取资源;
- Update: 更新资源, 不支持回滚.
我们说用户的账户余额啊, 它作为一个消耗型资源, 我们可以通过读取来得知账户有多少钱. 通过消费 x 元的方式来减少它, 通过生产 x 元的方式来增加它.
而用户的身份信息呢, 它作为一个非消耗型资源, 我们可以通过读取来得知用户的身份信息, 通过更新来修改用户的身份信息.
以上啊, 我们定义了一通概念, 那么这些概念到底有什么用呢? 请考虑以下情况:
- 一种典型的业务逻辑, 我们先从数据库中读取出用户的账户余额, 然后做一通判断, 结合一通相关的业务逻辑, 最后扣减 5 元后更新回数据库.
为了避免在此操作进行中账户余额被其他进程更新的情况, 通常我们要开启事务, 并结合 select... for update 语句来明确地给资源加锁. - 另一种情况, 管理员 A 从数据库中查出某一用户的用户信息, 一番操作后, 把修改后的用户信息更新回了数据库.
如果在此过程中, 管理员 B 更新了这个用户的信息, 那么最终管理员 B 的修改会被管理员 A 的修改覆盖掉, 而这个事实管理员 A 甚至都意识不到.
针对第一种情况, 账户余额属于消耗型资源, 那么相应的它只有三种操作. 可以做如下实现:
- select account from customer_account;
- update customer_account set account = account - x where account >= x;
- update customer_account set account = account + x;
针对第二种情况, 可以结合 version 字段实现如下:
- select info, version from customer_info;
- update customer_info set info = someinfo, version = versioin + 1 where version = oldversion;
最佳实践
一般, 如果业务流程涉及到消耗型资源, 理论上消费操作可能失败, 生产操作则一定能成功. 所以, 应该把所有的消费操作放在业务流程的最开始处, 所有的生产操作放到业务的结尾处. 其中任何一步消费操作失败, 或者中间的业务流程失败, 那么所有已成功的消费操作要回滚. 消费操作的回滚可以通过对应的生产操作来完成.
如果业务逻辑涉及到单个非消耗型资源, 那么其更新操作可能失败, 且不可回滚. 所以它的更新操作应该置于业务逻辑的结尾处. 如果业务逻辑涉及到多个非消耗型资源, 此时没有理论上的完美解决方案 (当然可以依赖事务啦).
只要业务流程设计得当, 通常可以做到避免在分布式环境中对事务的依赖 (考虑到分布式事务的实现是一项繁琐的工程).
还有就是, 在设计数据库表时, 请将消耗型资源和非消耗型资源置于不同的表, 这样可以避免处理逻辑的复杂化. 比如用户的账户, 积分等消耗型资源一张表, 用户的姓名, 年龄, 地址等非消耗型资源另外一张表.
