江苏龙网

  1. 首页 > 生活 > >

怎样避免无状态的RESTful中订单的重复提交

很大程度上取决于你的架构是怎么做的我个人认为首先，所有request必须有一个主键（id）。这个主键必须是根据某些关键信息生成的——因为你的应用场景里你是会把某些请求判定为“重复”的。那么你就要分析出请求被判定为重复的条件是什么，然后根据这个条件生成主键。其次，如果你已经开始做买卖数据了，那么你所有的数据库操作都应该是当作事务处理的。那么你的处理流程大概应该是这样：服务器收到请求事务开始对请求数据库进行读锁定，然后查询本ID是否已经写入本步骤也可以通过写入时是否报错（违反unique约束）来判断如果该ID已存在，报错，退出解锁对请求数据库进行写锁定，请求的ID被写入请求数据库，且状态被标为“处理中”其他业务流程事务结束返回“处理完成”如果事务中任何一步出现错误，那么就整个事务回滚，然后返回错误根据你的具体业务需求，事务结束的判定点可能不一样。但是大致流程应该没有区别。你所问的是标黑的这一段。这一段必须有。如果这部分逻辑要在数据库端做的话，可以依靠追加UNIQUE约束的方式进行----------------另外这个问题不是RESTful独有，甚至跟有没有状态都无关。
■网友
你搞2张表不就完了，确认中的订单单独进一张表，用户id，商品id作唯一主键。等卖家确认了再移到订单表。
■网友
在rest规范下 想办法把post请求改为put请求因为put请求是幂等的 所以重复提交结果也是一样的至于具体方法可以在提交购买请求前 先请求一个uuid作为这次操作的主键然后再在put的时候带上这个uuid
■网友
不带 ETag 也好意思说自己是 RESTful ?
■网友
处理方案：生成唯一流水号唯一流水号，可以客户端生成，也可以服务端生成。服务端可根据userId+业务主键Id+客户端时间戳+客户端随机数（可以用多个字段，或所有提交内容生成唯一串）客户端控制：客户端控制唯一流水只能提交一次，服务端未返回，不允许重复提交。服务端控制：服务端获取该唯一流水号的锁，如果获取不到锁表明之前已存在提交，事物处理完释放锁，业务级别根据唯一主键自行判断。一句话总结：全局用户级别事务锁可解决重复提交。
■网友
你描述的问题和 Restful 有什么关系？


    推荐阅读


    上一篇：家居设计平台Houzz模式在中国有机会吗

    下一篇：电脑重置，文件丢失咋找回