后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
2369 人已学习
课程目录
已更新 6 讲 / 共 26 讲
0/4登录后，你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 从今天起，换种方式学存储
免费
课前加餐| 电商系统是如何设计的？
创业篇 (4讲)
01 | 创建和更新订单时，如何保证数据准确无误？
02 | 流量大、数据多的商品详情页系统该如何设计？
03 | 复杂而又重要的购物车系统，应该如何设计？
04 | 事务：账户余额总是对不上账，怎么办？
后端存储实战课
登录|注册
04 | 事务：账户余额总是对不上账，怎么办？
李玥 2020-03-05
你好，我是李玥。今天这节课我们来说一下电商的账户系统。
账户系统负责记录和管理用户账户的余额，这个余额就是每个用户临时存在电商的钱，来源可能是用户充值或者退货退款等多种途径。
账户系统的用途也非常广泛，不仅仅是电商，各种互联网内容提供商、网络游戏服务商，电信运营商等等，都需要账户系统来管理用户账户的余额，或者是虚拟货币。包括银行的核心系统，也同样包含一个账户系统。
从业务需求角度来分析，一个最小化的账户系统，它的数据模型可以用下面这张表来表示：
这个表包括用户 ID、账户余额和更新时间三个字段。每次交易的时候，根据用户 ID 去更新这个账户的余额就可以了。
为什么总是对不上账？
每个账户系统都不是孤立存在的，至少要和财务、订单、交易这些系统有着密切的关联。理想情况下，账户系统内的数据应该是自洽的。所有用户的账户余额加起来，应该等于这个电商公司在银行专用账户的总余额。账户系统的数据也应该和其他系统的数据能对的上。比如说，每个用户的余额应该能和交易系统中充值记录，以及订单系统中的订单对的上。
不过，由于业务和系统的复杂性，现实情况却是，很少有账户系统能够做到一点不差的对上每一笔账。所以，稍微大型一点儿的系统，都会有一个专门的对账系统，来核对、矫正账户系统和其他系统之间的数据差异。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(9)
李玥 置顶hi，我是李玥。
我们还是回顾一下上节课留的思考题，是这样的。
既然用户的购物车数据存放在MySQL或者是Redis中各有优劣势。那能不能把购物车数据存在MySQL中，并且用Redis来做缓存呢？这样不就可以兼顾两者的优势了么？这样做是不是可行？如果可行，如何来保证Redis中的数据和MySQL中的数据是一样的呢？
关于这个问题，我这样看。
用Redis给购物车库做缓存，技术上肯定是可行的。但是有两个问题需要思考一下。
第一个问题是，值不值得这样做？因为每个人的购物车都是不一样的，所以这个缓存它的读写比差距不会很大，缓存的命中率不会太高，缓存的收益有限，为了维护缓存，还要增加系统的复杂度。所以我们就要自行权衡一下，是不是值得的问题。我的观点是，除了超大规模的系统以外，没有必要设置这个缓存。
第二个问题是，如果我们非要做这样一个缓存，用什么缓存更新策略更好呢？这里我先卖个关子，在《11 | MySQL如何应对高并发（一）：使用缓存保护MySQL》这节课中，我们会专门讲到几种常用的缓存策略，你可以学完这节课之后，再回过头来想一下这个问题。2020-03-05
观弈道人这篇讲事务的文章，是遇到的讲的最清楚明白、恰到好处的一篇，没有提看似更本质、更唬人的各种锁，比如间隙锁等，可以说大部人也都不能清楚理解各种锁，对于非专职dba理解此篇的知识技巧足够了。2020-03-05 2
慌张而黑糖其中在更新账户余额时的where log_id=3这部分感觉和乐观锁中的version起到的作用很像2020-03-05 1
肥low首先赞一下排版 问题难道是想问MVCC么 两种级别生成快照时机不同？2020-03-05- suke老师，那更新失败的情况一般电商系统该如何处理？是要继续尝试？还是直接返回失败2020-03-05 2
每天晒白牙又巩固了一遍事务的问题，不过这块确实容易蒙，尤其是面试中，还是需要自己下去梳理整理一下，加深印象2020-03-05
墨雨我在考虑的是，更新账户余额的时候是不是应该同时更新一下最后一笔交易流水的id呢？2020-03-05
赵冲老师，DDL语句，为什么插入流水表时，不记录账户余额表的主键呢？2020-03-05 1
CranliuRR级别下加的是next-key锁，可以解决幻读的吧？2020-03-05 1
收起评论