3
请教秒杀抢购架构设计问题
source link: https://www.v2ex.com/t/878258
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
需求：用户可以抢购某个商品，提交信息后跳转到指定页面（ http:\\host\productId\userId ）等待刷新，后台任务队列处理完成后，刷新出抢购的订单信息。
这样可以等待 order_table 出现相应的 productId 和 userId 的记录出现时能正确刷新出订单信息。
但是，如果 order_table 已经有该 productId 和 userId 的记录或者允许多次抢购，order_table 会出现多条 productId 和 userId 的记录，该怎么确定指定的订单信息呢？
我暂定是前端生成一个 uuid ，跳转到： http:\\host\productId\userId\uuid 等待刷新，uuid 存进该条记录到 order_table 。
各位老哥，你们也是类似这样设计的吗？
另外，我看到很多文章设计抢购系统是在 redis 放进库存数量，抢购成功扣库存，类似的设计。
我想，能不能生成预备订单数据，库存 100 个，就先生成 100 个预备订单，抢购时就查找有无预备订单，有的话就把用户信息放进该预备订单，就表示抢购成功。
问：在每次订单只允许抢购一个商品的前提下，是否方法二的可靠性更强？
这样可以等待 order_table 出现相应的 productId 和 userId 的记录出现时能正确刷新出订单信息。
但是，如果 order_table 已经有该 productId 和 userId 的记录或者允许多次抢购，order_table 会出现多条 productId 和 userId 的记录，该怎么确定指定的订单信息呢？
我暂定是前端生成一个 uuid ，跳转到： http:\\host\productId\userId\uuid 等待刷新，uuid 存进该条记录到 order_table 。
各位老哥，你们也是类似这样设计的吗？
另外，我看到很多文章设计抢购系统是在 redis 放进库存数量，抢购成功扣库存，类似的设计。
我想，能不能生成预备订单数据，库存 100 个，就先生成 100 个预备订单，抢购时就查找有无预备订单，有的话就把用户信息放进该预备订单，就表示抢购成功。
问：在每次订单只允许抢购一个商品的前提下，是否方法二的可靠性更强？
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK