支付系统39----支付宝支付,定时查单,每隔30秒执行1次,查询超过5分钟,并且未支付的订单

简介: 支付系统39----支付宝支付,定时查单,每隔30秒执行1次,查询超过5分钟,并且未支付的订单

106-尚硅谷-支付宝支付-定时查单_哔哩哔哩_bilibili

PaymentDemoApplication这里的@EnableScheduling的内容就是定时的意思

我们在AliPayTask下面创建一个类

写入一个@Component组件自动的定时任务呈现出来

写一个@Slf4j可以将日志给写出来

给他写一个查单的配置

每隔30秒执行1次,查询超过5分钟,并且未支付的订单

这个表达式的意思是每隔30秒执行1次

之后想要修改时间,就要在这里进行修改

现在注入我们Service对象

这里内容是减去什么时候,得出的秒数

这句话的意思是查询超过1分钟的订单

之后返回我们的数据列表

这里有支付宝的支付订单内容,未支付

控制台会每割30秒执行一次

这里我们想传入一个支付宝和微信的类型,添加一个参数 在我们的wx中也添加相应的参数

将我们String paymentType给添加上

找到Impl当中,将这些参数给加上

给你做一个范围更小的查询

这一次只查到了支付宝的界面


相关文章
|
存储 监控 NoSQL
一篇搞定Redis中的BigKey问题
BigKey的具体表现是redis中的key对应的value很大,占用的redis空间比较大,本质上是大value问题。
1840 0
|
消息中间件 NoSQL Kafka
订单超时取消的11种方式(非常详细清楚)
订单超时取消的11种方式(非常详细清楚)
9540 6
订单超时取消的11种方式(非常详细清楚)
|
7月前
|
消息中间件 存储 人工智能
官宣上线!RocketMQ for AI:企业级 AI 应用异步通信首选方案
RocketMQ 专门为 AI 场景推出了全新Lite Topic 模型,目前已在阿里云云消息队列 RocketMQ 版 5.x 系列实例上正式发布,并会逐步贡献到 Apache RocketMQ 开源社区,欢迎大家使用。
624 65
|
11月前
|
消息中间件 缓存 监控
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
|
6月前
|
供应链 安全 API
淘宝、京东、拼多多API大比拼,谁才是电商运营的最佳拍档?
本文深度对比淘宝、京东、拼多多三大电商平台API,从接口丰富度、性能稳定性、开发友好度、安全认证及商业成本五大维度分析,助您根据业务需求精准选择高效“技术拍档”,提升电商运营效率。
|
Java 中间件 调度
SpringBoot整合XXL-JOB【03】- 执行器的使用
本文介绍了如何将调度中心与项目结合,通过配置“执行器”实现定时任务控制。首先新建SpringBoot项目并引入依赖,接着配置xxl-job相关参数,如调度中心地址、执行器名称等。然后通过Java代码将执行器注册为Spring Bean,并声明测试方法使用`@XxlJob`注解。最后,在调度中心配置并启动定时任务,验证任务是否按预期执行。通过这些步骤,读者可以掌握Xxl-Job的基本使用,专注于业务逻辑的编写而无需关心定时器本身的实现。
5178 10
SpringBoot整合XXL-JOB【03】-  执行器的使用
|
存储 SQL 数据库
性能调优:优化 GROUP BY——使用索引字段分组减少临时文件生成
性能调优:优化 GROUP BY——使用索引字段分组减少临时文件生成
1200 1
|
消息中间件 NoSQL Java
订单出现超时未关闭场景解决方案
订单出现超时未关闭场景解决方案
790 5
|
消息中间件 存储 资源调度
订单超时怎么处理?我们用这种方案
在电商业务下,许多订单超时场景都在24小时以上,对于超时精度没有那么敏感,并且有海量订单需要批处理,推荐使用基于定时任务的跑批解决方案。
2863 108
订单超时怎么处理?我们用这种方案
|
机器学习/深度学习 存储 测试技术
从0到1:如何规划一套流量回放自动化测试方案
本文介绍了流量回放自动化测试的完整方法,从企业战略到交付的四个关键环节:Discovery(深度挖掘)、Define(定义目标)、Design(详细设计)和Delivery(交付与反馈)。通过这些步骤,帮助企业优化系统性能和稳定性,确保产品的高质量。
567 4

热门文章

最新文章