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

在实际项目中,因为订单创建可能过多,需要用到 Redis ,但是,通过查询、搜索,发现队列大部分都是应用到秒杀、抢购、消息队列,没有搜索到使用 Redis 来创建订单的。
曾尝试过使用 $redis->lpush('room_order',$insert)  添加,发现它并没有分组存储(一个订单的所有信息为一个分组), 也曾尝试过 Set 集合,但是它集合成员是唯一的,所以也被我否决了,目前没有一个好的解决办法,所以看看各位有什么好的思路可以提供谢谢,还有 redis 释放资源 是否是 close(),在项目中直接应用会报错。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
LDL1023
最佳答案

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

如果是想利用 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:

2个月前 评论
讨论数量: 24

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论
CrazyZard

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

2个月前 评论

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

2个月前 评论
CrazyZard

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

2个月前 评论
巴啦啦

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

2个月前 评论
Max

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

2个月前 评论
CrazyZard

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

2个月前 评论
Max

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

2个月前 评论
CrazyZard

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

2个月前 评论

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

2个月前 评论
Max

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

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

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

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

2个月前 评论

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

2个月前 评论
CrazyZard

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

2个月前 评论

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

2个月前 评论

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

2个月前 评论
LDL1023

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

如果是想利用 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:

2个月前 评论

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

2个月前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!

社区文档:

将托管在 packagist.org 和 github.com 的扩展包使用国内 CDN 加速
GitHub Laravel 扩展包 TOP 250
速查表方便快速查询框架功能,支持手机访问,支持中英文版本
Laravel 中文文档,由社区用户翻译和维护,将会保持一直更新
此文档的目的,就是为了提高技术团队的凝聚力、一致性和生产效率。
开发环境的部署,开发者工具的选择,适用于 Mac 和 Windows。
浓缩过后的精华
Laravel Nova 后台管理面板文档的中文翻译
Lumen 中文文档,由社区用户翻译和维护,将会保持一直更新
Laravel 下知名扩展包 Dingo API 的中文文档,Laravel API 开发必知必会