如何使用互联网技术来设计和制作支付交易系统和抢红包

业务幂等带来的性能上的损耗

交易系统讲究的是：业务幂等，不能多扣不能少扣。

比如说有一个用户他的帐户余额就10,000元，无论它进行了上万、上千次交易，每一笔交易成功的流水的状态、和金额必须要对的起来。说了简单点假设该帐户交易了100次，共计9万元的交易流水，但帐户余额就10,000，你不能给他记成负8万余额吧？那么我们来看这个100次交易流水。其中有30次交易成功，总额是10,000元扣款成功。其余70次都是交易失败。如果30次交易成功，总额是10,000元，然后如果出现了第31次也是交易成功，那么这第31次的交易成功怎么来的？这就是业务不幂等。

演示根据交易额扣款动作

根据业务需求与设计

我们下面可以来演示，不幂等时发生的代码问题

数据库表结构如下：

uid	Balance
2	1000

我们做一个spring boot的controller、service、dao，然后使用多个并发对这一个帐户里的余额进行操作。

每次操作，我们带着一个“扣除100元”的动作来访问这个帐号，根据传入的扣款来对