怎么解决http频繁请求同一接口，但数据库来不及写入导致数据不一致的问题

场景是这样的：
客户端向服务器发送一条用户的支付请求，服务器接收到请求后查询数据库，假如当前用户的消费记录未完成支付，且与请求支付数额吻合，执行支付，生成一条支付记录，否则返回提示信息。
问题：在业务场景网络环境复杂的情况下（例如网络卡顿延时），客户端发起的支付请求未能及时送达服务器，此时客户端取消等待，重新发起一次支付请求。然后服务器在同一时间收到2次支付请求，因数据库没来得及执行更新数据，导致查询数据库结果一致，为“可以支付”！则生成2条支付记录信息，其中一条属于脏数据。
根源：支付记录可以产生多条，且不受外键限制，支付接口属于公用且调用频繁的关键接口，不能使用全局同步锁，最好能用资源id绑定的形式让其同步，例如发起请求的用户id一致，则进入同步
工作一年，经验太少，有什么方案可以解决这种问题，谢谢

解决方案

引用:

Quote: 引用:
感觉题主说的更像是表单重复提交问题吧？假如用户刻意的在点击一条之后，服务端生成相应数据并反馈后，再次点击，那肯定要按逻辑服务端再生成数据，谁让他点两次呢？假如说是由于网络问题用户频繁的点击提交，为预防这种情况可以做个防止表单重复提交的拦截

有点相似，但不是表单重复提交，客户端是Android，第二次请求是客户端主动取消等待界面，关闭后再次发起的一个请求，对于服务器和客户端来说都是新请求不是重复提交。本人现在的临时解决方案是客户端加大超时时间，同时点击提交后锁定界面，不允许在超时前再发起请求。治标不治本吧

既然题主允许主动取消再提交的话，那就只能是服务器端作判断了，当服务器端收到请求时，判断一下能否请求已经处理过了，至于判断规则，可以在手机发送时优先生成一个请求序列UUID，假如取消再提交，则UUID不变，否则每次UUID都改变

数据库事务还没commit，下一个交易过来，查询数据库还是没update的数据，所以出问题
这种情况下最好权衡一下你们系统的性能和一致性需求，假如性能可以接受，数据库加行级甚至表一级锁，这样下一个交易来只有等上一交易commit才查得到数据，假如性能是优先考虑，那只有加其他的判断依据了

配置事务的隔离级别为read committed（能读到不同事务已提交到的数据）可以解决你的问题

引用:

Quote: 引用:
客户端增加交易流水号，服务端使用一个表记录此流水号交易状态，首次收到请求时先设定此流水号为正在操作中，服务端执行完成，修改此流水号的执行结果状态。可以简化主业务数据库的锁表

只要涉及到数据库且不锁，就可能会存在对同一组数据的并发读写=。= ，假如正在更新流水号时产生并发读，结果是一样的

流水号表锁表比交易数据相关表锁表多系统影响轻很多