对保存订单的理解
1. 后端接口设计
请求方式 : POST /orders/
请求参数: JSON 或 表单
参数 | 类型 | 是否必须 | 说明 |
---|---|---|---|
address | int | 是 | 收货地址id |
pay_method | int | 是 | 支付方式 |
返回数据: JSON
参数 | 类型 | 是否必须 | 说明 |
---|---|---|---|
order_id | char | 是 | 订单编号 |
def create(self, validated_data): # 获取当前下单用户 # 生成订单编号 # 保存订单基本信息数据 OrderInfo # 从redis中获取购物车结算商品数据 # 遍历结算商品: # 判断商品库存是否充足 # 减少商品库存,增加商品销量 # 保存订单商品数据 # 在redis购物车中删除已计算商品数据
在多个用户同时发起对同一个商品的下单请求时,先查询商品库存,再修改商品库存,会出现资源竞争问题,导致库存的最终结果出现异常。
使用乐观锁,在更新的时候判断此时库存是否是之前查询的库存,如果相同,表示没人修改过,可以更新,否则表示有人抢占过资源,不在执行库存更新。返回重新创建订单,直至库存不够。
需要修改mysql的事物隔离级别
事务隔离级别指的是在处理同一个数据的多个事务中,一个事务修改数据后,其他事务何时能看到修改后的结果。
MySQL数据库事务隔离级别主要有四种:
- Serializable 串行化,一个事务一个事务的执行
- Repeatable read 可重复读,无论其他事务是否修改并提交了数据,在这个事务中看到的数据值始终不受其他事务影响
- Read committed 读取已提交,其他事务提交了对数据的修改后,本事务就能读取到修改后的数据值
- Read uncommitted 读取为提交,其他事务只要修改了数据,即使未提交,本事务也能看到修改后的数据值。
MySQL数据库默认使用可重复读( Repeatable read),而使用乐观锁的时候,如果一个事务修改了库存并提交了事务,那其他的事务应该可以读取到修改后的数据值,所以不能使用可重复读的隔离级别,应该修改为读取已提交Read committed。