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

xyq1986 2019-02-04 09:39:47
mysql垂直分库:用户余额一个库,订单表一个库,资金明细一个库。 用户采用余额下单,余额后马上下单成功,怎么在大并发情况下保证不会被多下单(余额100却能下多单100元的)且数据一致。
...全文
1587 13 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
别闹腰不好 2019-03-01
  • 打赏
  • 举报
回复
redis 分布式锁,setNX() 用户维度的分布式锁, mysql 也能实现分布式锁。
stacksoverflow 2019-02-28
  • 打赏
  • 举报
回复 2
tcc补偿型事务,预处理的时候冻结余额,下单成功后用冻结的记录把余额扣掉,把冻结记录清除,下单失败后把冻结记录清除。
哈希塞特 2019-02-28
  • 打赏
  • 举报
回复
看你想一致到什么程度,强一致就需要单独搭建一个事物协调服务,用两阶段三阶段提交,但是并发能力不高。 只要达到最终一致就可以用mq事物,用rocketmq有现成的接口可用,其他mq需要自己维护本地消息表,记录失败的事物,定期回滚补偿。 你说的是大并发,那就应该用mq事物。
angel6709 2019-02-15
  • 打赏
  • 举报
回复
为啥不让多下蛋
HHeyJ 2019-02-15
  • 打赏
  • 举报
回复
如果我没理解错的话,这种业务场景可以采用乐观锁
  • 打赏
  • 举报
回复
分布式事物控制
开拓者Amadues 2019-02-13
  • 打赏
  • 举报
回复
引用 4 楼 bcsflilong 的回复:
我真不知道楼上在那说的是什么,你这种场景是分布式事务
楼主说了避免“余额100却能下多单100元的”,这个就是锁。
zxm213 2019-02-12
  • 打赏
  • 举报
回复
新人报到,谢谢各位老师
  • 打赏
  • 举报
回复
不可能分布式事务,性能太差,你要做的就是保证幂等,每笔交易都有一个流水号,流水号做唯一键
bcsflilong 2019-02-11
  • 打赏
  • 举报
回复
我真不知道楼上在那说的是什么,你这种场景是分布式事务
开拓者Amadues 2019-02-06
  • 打赏
  • 举报
回复
但如果你的金额扣费计算需要在应用层完成的,那就比较麻烦,我自己做的话只会手动在应用层加锁,也就是让每笔业务操作排队,但这样会降低不少性能。 还有我看到应用是多节点的时候,因为涉及到多台不同的服务器,只在本服务器排队还不够,要多台服务器一起考虑加锁,那样就更麻烦了。
开拓者Amadues 2019-02-06
  • 打赏
  • 举报
回复
你标题是事务性,但内容我看是跟锁有关的。 直接update 表 set 余额 = 余额 - xx就可以了,不管你前端有多少用户同时请求,数据库表这里总有一个先后的(数据库内部也有锁),更新完之后读一下,如果其中某一笔交易的费用大于余额就报错并回滚。
十八道胡同 2019-02-04
  • 打赏
  • 举报
回复
这个就是分布式事务的应用场景 分布式事务保障订单和余额一致性,要成功都成功,要失败都失败

67,550

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧