Laravel 中 订单创建如何使用 Redis 队列

还有搜索到他们使用 Redis 都是创建订单号，提前生成订单号，给明日的订单直接使用

@li1760162 创建大量的订单和Redis这个没有必然的联系吧，您的意思是否是：如何更好的大量生成订单？

刚想到个想法，把订单的所有数据存储到一张表中，然后把表的id 存储到 redis 中 挨个 去调用 移除 这个思路是否正确

@mojiajuzi 嗯，是的，可以这么理解

@mojiajuzi 在生成订单的时候不能被堵塞

@li1760162 能把具体的场景说一下吗？

@mojiajuzi 具体场景是比如去超市买东西，一件商品就是一条订单，现在有多个商品，也就是有多个订单，同时需要生成，现在这是一家超市 ，如果是多家超市，同时去做开单操作

目前我的思路是他单个用户生成的多个订单时，先把订单的数据存储到一个临时表中，不去生成，然后把单个用户的所有订单去生成一个同一 id 存储到 Redis 中，开单时 取出一个 id 然后进行开单操作，所有关联订单数据 开单完成后 把 Redis 中存储的 id 去进行移除操作 ，这种思路是否正确

Redis 的hash 你了解下 你可以把生成的订单 作为一个key 再把每个商品编码放进去 有效期设下

@CrazyZard 我去尝试下，谢谢提供的思路，我上面提到的思路是否正确呢？

我的感觉 你就像是个 购物车的概念 到结账的时候 在去生成唯一编码

可以不引入购物车的概念，分成两张表，第一张表记录订单 order ，第二章表记录订单中的每一件商品 order_info，一条 order 记录对应多条类型不同的 order_info。

我有个疑问，就是如果大量创建订单(post)支撑不住的话，那稍后支付成功的大量回调（put）,关于支付结果的大量查询（get） 这些地方是否都会支撑不住，需要全程 redis 么？

@Max 你说的太笼统了 这个流程走下来 有很多种方法 具体问题 具体分析

@CrazyZard 我说这三个算是关系很紧密的三个流程，无论是发生的时间，还是逻辑上的相互影响。最近在思考秒杀，想到了这个问题。

@Max 首先你根据你的业务 是否能撑得住 数据库为啥会 撑不住？ 是大量查询卡 还是 查询时间慢 数据库的cpu 飙升到100% 了没 查询做缓存了嘛 ？查询优化了嘛？ 做业务之前 先看量大不大 老板 说上千万并发量 有技术总监在那顶着

秒杀应该数量有限吧 秒杀货物的数量 通过redis的自增原子性操作做-1数量操作 再配合list队列 应该不会出现大量的回调

@CrazyZard 所以现在是 题主说同事创建的订单数量太多，要用 redis 来创建（看意思是，临时存储在 redis ,而不是用队列 来缓解数据库压力）呀 你跟我说也没有用呀 :flushed:

我的意思和楼上一样，一般秒杀其实只是查询库存（通过 redis 缓存库存）的人很多，最后创建订单的人不多，最后请求的压力完全不在数据库这里。
但是假如，创建订单的人也很多（并发）的话， 如果库存足够，那就生成一个订单号， 然后返回给前端让前端等待。
后端则把该订单号和 user_id 及 sku_id 交给异步队列（一个或多个队列，在数据库的承受能力即可），后端订单创建成功后 通过 websocket 通知前端必要的信息，让前端进行支付的发起。
这个队列处理的过程，相当于（通过让用户等待）把请求进行了限流，从而减少了从创建订单/支付/回调 等后续的并发压力。

由于没有做过秒杀，这是我心理模拟的一个秒杀处理流程。

订单绝不单单指 一个 sku_id,price,user_id。 相关的关联信息，如促销（超市尤其）的/运费等计算都是非常耗费数据库和服务器资源的。所以我觉得订单信息放在 redis 里面是没啥意义的。 如果只是用 redis 做为 queue 的驱动，在 queue 中创建订单我觉得是可行的

emmmm...那还是如题 我把订单分开存储 ，一种是 一个用户支付的所有订单存储一个表，然后另外在存储一个支付的订单表， 那么这种情况下我是否可以把他加入缓存？以此来达到优化的目的？

主从表的概念是可以的 但这是建立在已支付的情况下 如果出现大量的还未支付 但需要显示 就需要在redis建立缓存 并设置失效时间 并监听 真的要这么做 可以参考 https://www.jianshu.com/p/588891acd44c

订单表 订单与商品的映射表（订单id 商品id 购买的数量 ...） 商品表 三者之间就能实现用户多订单多商品了吧

好吧我从头看到尾不知道在说什么，问题到底在哪里？在生成订单的时候不能被堵塞，你说的是哪里被堵塞了，数据库不行就主从啊，服务器不行就均衡啊，redis可以加一层库存判断的缓存，最后是否下单成功还是要看mysql的库存是否合法，接受延迟就用消息队列，下单了就发个消息，跑个消费者慢慢刷

我觉得题主没有很好地把问题描述清楚。

如果是想利用 Redis 消息队列来创建订单，没必要

$redis->lpush('room_order',$insert) 

这样创建

可以参考文档 https://learnku.com/docs/laravel/5.8/queues 配置好 Laravel 的 Redis 消息队列，然后

$order = [
    ...

    'sku_id' => 123,
    'user_id' => 123,

    ...
];
CreateOrder::dispatch($order);

也不用去处理释放 redis 的资源

希望对题主有帮助~ :grin: :grin:

@LDL1023 我自己也不是很清楚，只是有一点很明白，订单在生成时尽量不能堵塞，尽可能的去优化