用户余额下单如何保证数据一致性

[xyq1986]

mysql垂直分库：用户余额一个库，订单表一个库，资金明细一个库。 用户采用余额下单，余额后马上下单成功，怎么在大并发情况下保证不会被多下单（余额100却能下多单100元的）且数据一致。

[十八道胡同]

这个就是分布式事务的应用场景 分布式事务保障订单和余额一致性，要成功都成功，要失败都失败

[开拓者Amadues]

你标题是事务性，但内容我看是跟锁有关的。 直接update 表 set 余额 = 余额 - xx就可以了，不管你前端有多少用户同时请求，数据库表这里总有一个先后的（数据库内部也有锁），更新完之后读一下，如果其中某一笔交易的费用大于余额就报错并回滚。

[开拓者Amadues]

但如果你的金额扣费计算需要在应用层完成的，那就比较麻烦，我自己做的话只会手动在应用层加锁，也就是让每笔业务操作排队，但这样会降低不少性能。 还有我看到应用是多节点的时候，因为涉及到多台不同的服务器，只在本服务器排队还不够，要多台服务器一起考虑加锁，那样就更麻烦了。

[bcsflilong]

我真不知道楼上在那说的是什么，你这种场景是分布式事务

[道不虚行只在人]

不可能分布式事务，性能太差，你要做的就是保证幂等，每笔交易都有一个流水号，流水号做唯一键

[zxm213]

新人报到，谢谢各位老师

[开拓者Amadues]

引用 4 楼 bcsflilong 的回复:

我真不知道楼上在那说的是什么，你这种场景是分布式事务

楼主说了避免“余额100却能下多单100元的”，这个就是锁。

[神界码农-D-艾斯]

分布式事物控制

[HHeyJ]

如果我没理解错的话，这种业务场景可以采用乐观锁

[angel6709]

为啥不让多下蛋

[哈希塞特]

看你想一致到什么程度，强一致就需要单独搭建一个事物协调服务，用两阶段三阶段提交，但是并发能力不高。 只要达到最终一致就可以用mq事物，用rocketmq有现成的接口可用，其他mq需要自己维护本地消息表，记录失败的事物，定期回滚补偿。 你说的是大并发，那就应该用mq事物。

[stacksoverflow]

tcc补偿型事务，预处理的时候冻结余额，下单成功后用冻结的记录把余额扣掉，把冻结记录清除，下单失败后把冻结记录清除。

[别闹腰不好]

redis 分布式锁，setNX() 用户维度的分布式锁， mysql 也能实现分布式锁。