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

[xllove_moon]

场景是这样的：
客户端向服务器发送一条用户的支付请求，服务器接收到请求后查询数据库，如果当前用户的消费记录未完成支付，且与请求支付数额吻合，执行支付，生成一条支付记录，否则返回提示信息。

问题：在业务场景网络环境复杂的情况下（比如网络卡顿延时），客户端发起的支付请求未能及时送达服务器，此时客户端取消等待，重新发起一次支付请求。然后服务器在同一时间收到2次支付请求，因数据库没来得及执行更新数据，导致查询数据库结果一致，为“可以支付”！则生成2条支付记录信息，其中一条属于脏数据。

根源：支付记录可以产生多条，且不受外键限制，支付接口属于公用且调用频繁的关键接口，不能使用全局同步锁，最好能用资源id绑定的形式让其同步，比如发起请求的用户id一致，则进入同步

工作一年，经验太少，有什么方案可以解决这种问题，谢谢

[xllove_moon]

引用 1 楼 zoeg 的回复:

『导致查询数据库结果一致，为“可以支付”！则生成2条支付记录信息』 这句话说明你检测数据一致性和数据更改落实没有在一个数据库事务周期内完成。 你应该提高隔离级别如： 1、Connection..setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); 2、Connection.setAutocommint(false); 3、查询数据是否存在； 4、插入纪录，如果需要； 5、Connection.commit()或者Connection.rollback();

实际上是这样的：第一个请求到达，服务器查询后允许支付，此时后台进入第一个请求的支付处理逻辑，在这时第二个请求到达，因第一个请求刚开始处理并未处理完成，数据库数据并未产生变化，所以也得到可以支付的判定，第二个请求也进了支付逻辑=。=

[Mr_yyy]

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

[Mr_yyy]

也可以类似支付宝那种，当你点击支付后，直接弹出另一个页面，而本页面立即变为：支付成功or失败？ 这样也可以防止其重复提交

[xllove_moon]

引用 3 楼 Mr_yyy 的回复:

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

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

[Mr_yyy]

引用 5 楼 qsxy1991 的回复:

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

有点类似，但不是表单重复提交，客户端是Android，第二次请求是客户端主动取消等待界面，关闭后再次发起的一个请求，对于服务器和客户端来说都是新请求不是重复提交。。。我现在的临时解决方案是客户端加大超时时间，同时点击提交后锁定界面，不允许在超时前再发起请求。。治标不治本吧[/quote]既然楼主允许主动取消再提交的话，那就只能是服务器端作判断了，当服务器端收到请求时，判断一下是否请求已经处理过了，至于判断规则，可以在手机发送时优先生成一个请求序列UUID，如果取消再提交，则UUID不变，否则每次UUID都改变

[qingyuan18]

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

[xllove_moon]

引用 7 楼 qingyuan18 的回复:

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

可以考虑锁行，不给读，结算涉及的表有好几个，锁行也要锁N多个，而且锁表会影响其他业务的效率

[zoeg]

不管怎么做，最终一定是在某个统一的地方做互斥的。比如： 1、为你的消费记录增加一个字段，标记是否已开始支付，甚至就记录支付请求的序列号，每当发起支付请求时首先更改该字段用以避免新的请求再次发起，更好的体验是新的请求会还原刚才中断的操作，继续后续的流程； 2、虽然你说支付记录可以被1：N，不能加锁，但是你可以创建一个新的支付流水表用来锁定某个消费记录的互斥状态，生命周期可以很短，代价不算高； 等等等。。。 所以解决的思路大致是，如果现有的结构能够找到一个切入点加锁就用现有的，如果没有就刻意增加一个数据存储，迫使记录与数据对应，用这个新的数据加锁。这有点类似文件的情况，有一个test.dat文件，很多进程都要读写，为了避免冲突，会在操作文件时创建test.lck文件用于被其他进程发现，该文件已经处于被操作状态，这个过程中的互斥并没有改变目标文件的任何内容，而是通过外部数据加锁。

[ilmlife]

引用 9 楼 zoeg 的回复:

不管怎么做，最终一定是在某个统一的地方做互斥的。比如： 1、为你的消费记录增加一个字段，标记是否已开始支付，甚至就记录支付请求的序列号，每当发起支付请求时首先更改该字段用以避免新的请求再次发起，更好的体验是新的请求会还原刚才中断的操作，继续后续的流程； 2、虽然你说支付记录可以被1：N，不能加锁，但是你可以创建一个新的支付流水表用来锁定某个消费记录的互斥状态，生命周期可以很短，代价不算高； 等等等。。。 所以解决的思路大致是，如果现有的结构能够找到一个切入点加锁就用现有的，如果没有就刻意增加一个数据存储，迫使记录与数据对应，用这个新的数据加锁。这有点类似文件的情况，有一个test.dat文件，很多进程都要读写，为了避免冲突，会在操作文件时创建test.lck文件用于被其他进程发现，该文件已经处于被操作状态，这个过程中的互斥并没有改变目标文件的任何内容，而是通过外部数据加锁。

更改字段的时候就并发了怎么办？两个线程同时获得这个字段发现当前是未开始支付

[zoeg]

『导致查询数据库结果一致，为“可以支付”！则生成2条支付记录信息』 这句话说明你检测数据一致性和数据更改落实没有在一个数据库事务周期内完成。 你应该提高隔离级别如： 1、Connection..setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); 2、Connection.setAutocommint(false); 3、查询数据是否存在； 4、插入纪录，如果需要； 5、Connection.commit()或者Connection.rollback();

[tianfang]

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

[xllove_moon]

引用 11 楼 q583900890 的回复:

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

思路还是行锁，对吧？

[xllove_moon]

引用 12 楼 tianfang 的回复:

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

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

[晴天_ccc]

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

[tianfang]

引用 14 楼 qsxy1991 的回复:

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

只要涉及到数据库且不锁，就可能会存在对同一组数据的并发读写=。= ，如果正在更新流水号时产生并发读，结果是一样的[/quote] 流水号表锁表比交易数据相关表锁表多系统影响轻很多

[放纵的青春]

交易启用队列排队 性能要求不那么高可以先上锁 保证数据一致性

[yaojian55]

可以在请求上做个时间验证，场景这样！当用户请求一次以后，在限定时间内用户如果多次发起请求，都视为无效请求！当然这个限定时间可以断一点！如果超过限定时间，按最新请求为准！