架构师之超时未支付的订单进行取消操作的几种解决方案

今天给大家上一盘硬菜,并且是支付中非常重要的一个技术解决方案,有这块业务的同学注意自己尝试一把哈!

一、需求如下:

  • 生成订单30分钟未支付,自动取消

  • 生成订单60秒后,给用户发短信

对上述的需求,我们给一个专业的名字来形容,那就是延时任务。你可能会问延时任务和定时任务有啥区别呢?

一共有以下几点区别

  • 定时任务有明确的触发时间,延时任务没有

  • 定时任务有执行周期,而延时任务在某事件触发后一段时间内执行,没有执行周期

  • 定时任务一般执行的是批处理操作是多个任务,而延时任务一般是单个任务

二、解决方案

(1)数据库轮询

该方案通常是在小型项目中使用,即通过一个线程定时的去扫描数据库,通过订单时间来判断是否有超时的订单,然后进行update或delete等操作

1)引入依赖

<dependency>
    <groupId>org.quartz-scheduler</groupId>
    <artifactId>quartz</artifactId>
    <version>2.2.2</version>
</dependency>

2)创建Demo类实现

public class MyJobDemo implements Job {

    public void execute(JobExecutionContext context)
            throws JobExecutionException {
        System.out.println("我去访问数据库啦。。。");
    }

    public static void main(String[] args) throws Exception {

        // 创建任务
        JobDetail jobDetail = JobBuilder.newJob(MyJobDemo.class)
                .withIdentity("job1", "group1").build();

        // 创建触发器 每3秒钟执行一次
        Trigger trigger = TriggerBuilder
                .newTrigger()
                .withIdentity("trigger1", "group3")
                .withSchedule(
                        SimpleScheduleBuilder.simpleSchedule()
                                .withIntervalInSeconds(3).repeatForever())
                .build();

        Scheduler scheduler = new StdSchedulerFactory().getScheduler();
        // 将任务及其触发器放入调度器
        scheduler.scheduleJob(jobDetail, trigger);
        // 调度器开始调度任务
        scheduler.start();
    }
}

3)运行结果每3秒输出:

我去访问数据库啦。。。

优点:简单易行,支持集群操作

缺点:

(1)对服务器内存消耗大

(2)存在延迟,比如你每隔3分钟扫描一次,那最坏的延迟时间就是3分钟

(3)假设你的订单有几千万条,每隔几分钟这样扫描一次,数据库损耗极大

(2)JDK的延迟队列

该方案是利用JDK自带的DelayQueue来实现,这是一个无界阻塞队列,该队列只有在延迟期满的时候才能从中获取元素,放入DelayQueue中的对象,是必须实现Delayed接口的。

  • Poll():获取并移除队列的超时元素,没有则返回空

  • take():获取并移除队列的超时元素,如果没有则wait当前线程,直到有元素满足超时条件,返回结果。

1)定义一个类OrderDelay实现Delayed

public class OrderDelay implements Delayed {
    private String orderId;
    private long timeout;

    OrderDelay(String orderId, long timeout) {
        this.orderId = orderId;
        this.timeout = timeout + System.nanoTime();
    }

    public int compareTo(Delayed other) {

        if (other == this)
            return 0;

        OrderDelay t = (OrderDelay) other;
        long d = (getDelay(TimeUnit.NANOSECONDS) - t
                .getDelay(TimeUnit.NANOSECONDS));

        return (d == 0) ? 0 : ((d < 0) ? -1 : 1);
    }

    // 返回距离你自定义的超时时间差值
    public long getDelay(TimeUnit unit) {
        return unit.convert(timeout - System.nanoTime(),TimeUnit.NANOSECONDS);
    }

    void print() {
        System.out.println(orderId+"编号的订单即将删除啦。。。。");
    }
}

2)运行的测试Demo为,我们设定延迟时间为3秒

public class DelayQueueDemo {
     public static void main(String[] args) {  
            List<String> list = new ArrayList<String>();  
            list.add("00000001");  
            list.add("00000002");  
            list.add("00000003");  
            list.add("00000004");  
            list.add("00000005");  

            DelayQueue<OrderDelay> queue = newDelayQueue<OrderDelay>();  

            long start = System.currentTimeMillis();  
            for(int i = 0;i<5;i++){  
                //延迟三秒取出
                queue.put(new OrderDelay(list.get(i),  
                        TimeUnit.NANOSECONDS.convert(3,TimeUnit.SECONDS)));  
                    try {  
                         queue.take().print();  
                         System.out.println("After " +  (System.currentTimeMillis()-start) + " MilliSeconds");  
                } catch (InterruptedException e) {}  
            }  
        }  
}

3)输出如下:

00000001编号的订单即将删除啦。。。。
After 3003 MilliSeconds
00000002编号的订单即将删除啦。。。。
After 6006 MilliSeconds
00000003编号的订单即将删除啦。。。。
After 9006 MilliSeconds
00000004编号的订单即将删除啦。。。。
After 12008 MilliSeconds
00000005编号的订单即将删除啦。。。。
After 15009 MilliSeconds

优点:效率高,任务触发时间延迟低。

缺点:

(1)服务器重启后,数据全部消失,怕宕机

(2)集群扩展相当麻烦

(3)因为内存条件限制的原因,比如下单未付款的订单数太多,那么很容易就出现OOM异常

(4)代码复杂度较高

(3)时间轮算法

时间轮算法可以类比于时钟,如上图箭头(指针)按某一个方向按固定频率轮动,每一次跳动称为一个 tick。

这样可以看出定时轮由个3个重要的属性参数

  • ticksPerWheel(一轮的tick数)

  • tickDuration(一个tick的持续时间)

  • timeUnit(时间单位)

例如当ticksPerWheel=60,tickDuration=1,timeUnit=秒,这就和现实中的始终的秒针走动完全类似了。

如果当前指针指在1上面,我有一个任务需要4秒以后执行,那么这个执行的线程回调或者消息将会被放在5上。那如果需要在20秒之后执行怎么办,由于这个环形结构槽数只到8,如果要20秒,指针需要多转2圈。位置是在2圈之后的5上面(20 % 8 + 1)

具体实现(使用Netty的HashedWheelTimer来实现):

1)引依赖:

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-all</artifactId>
    <version>4.1.24.Final</version>
</dependency>

2)创建HashedWheelTimerTest测试:

public class HashedWheelTimerTest {
    static class MyTimerTask implements TimerTask{
        boolean flag;
        public MyTimerTask(boolean flag){
            this.flag = flag;
        }

        public void run(Timeout timeout) throws Exception {
             System.out.println("我去数据库删除订单了。。。。");
             this.flag =false;
        }
    }

    public static void main(String[] argv) {
        MyTimerTask timerTask = new MyTimerTask(true);
        Timer timer = new HashedWheelTimer();
        timer.newTimeout(timerTask, 5, TimeUnit.SECONDS);
        int i = 1;
        while(timerTask.flag){
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            System.out.println("过去了"+i+"秒");
            i++;
        }
    }
}

3)输出如下:

过去了1秒
过去了2秒
过去了3秒
过去了4秒
过去了5秒
我去数据库删除订单了。。。。
过去了6秒

优点:效率高,任务触发时间延迟时间比delayQueue低,代码复杂度比delayQueue低。

缺点:

(1)服务器重启后,数据全部消失,怕宕机

(2)集群扩展相当麻烦

(3)因为内存条件限制的原因,比如下单未付款的订单数太多,那么很容易就出现OOM异常

(4)redis缓存

思路一

利用redis的zset,zset是一个有序集合,每一个元素(member)都关联了一个score,通过score排序来取集合中的值

相关的命令操作:

  • 添加元素:ZADD key score member [[score member] [score member] …]

  • 按顺序查询元素:ZRANGE key start stop [WITHSCORES]

  • 查询元素score:ZSCORE key member

  • 移除元素:ZREM key member [member …]

具体实现:我们将订单超时时间戳与订单号分别设置为score和member,系统扫描第一个元素判断是否超时,具体如下图所示

 1)代码实现:

public class AppTest {
    private static final String ADDR = "127.0.0.1";
    private static final int PORT = 6379;
    private static JedisPool jedisPool = new JedisPool(ADDR, PORT);

    public static Jedis getJedis() {
       return jedisPool.getResource();
    }

    //生产者,生成5个订单放进去
    public void productionDelayMessage(){
        for(int i=0;i<5;i++){

            //延迟3秒
            Calendar cal1 = Calendar.getInstance();
            cal1.add(Calendar.SECOND, 3);
            int second3later = (int) (cal1.getTimeInMillis() / 1000);
            AppTest.getJedis().zadd("OrderId",second3later,"OID0000001"+i);
            System.out.println(System.currentTimeMillis()+"ms:redis生成了一个订单任务:订单ID为"+"OID0000001"+i);
        }
    }

    //消费者,取订单
    public void consumerDelayMessage(){
        Jedis jedis = AppTest.getJedis();
        while(true){
            Set<Tuple> items = jedis.zrangeWithScores("OrderId", 0, 1);
            if(items == null || items.isEmpty()){
                System.out.println("当前没有等待的任务");
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                continue;
            }

            int  score = (int) ((Tuple)items.toArray()[0]).getScore();
            Calendar cal = Calendar.getInstance();
            int nowSecond = (int) (cal.getTimeInMillis() / 1000);

            if(nowSecond >= score){
                String orderId = ((Tuple)items.toArray()[0]).getElement();
                jedis.zrem("OrderId", orderId);
                System.out.println(System.currentTimeMillis() +"ms:redis消费了一个任务:消费的订单OrderId为"+orderId);
            }
        }
    }

    public static void main(String[] args) {
        AppTest appTest =new AppTest();
        appTest.productionDelayMessage();
        appTest.consumerDelayMessage();
    }
}

2)输出的时候会看到,几乎都是3秒后进行订单的消费,然而它有一个致命的伤,高并发条件下,多消费者会取到同一个订单号,也就是我们常说的超卖问题,显然,出现了多个线程消费同一个资源的情况。

针对这个问题的解决方案是:

(1)用分布式锁,但是用分布式锁,性能下降了,该方案不细说。

(2)对ZREM的返回值进行判断,只有大于0的时候,才消费数据,于是consumerDelayMessage()方法里的

if(nowSecond >= score){
    String orderId = ((Tuple)items.toArray()[0]).getElement();
    jedis.zrem("OrderId", orderId);
    System.out.println(System.currentTimeMillis()+"ms:redis消费了一个任务:消费的订单OrderId为"+orderId);
}

修改为:

if(nowSecond >= score){
    String orderId = ((Tuple)items.toArray()[0]).getElement();
    Long num = jedis.zrem("OrderId", orderId);
    if( num != null && num>0){
        System.out.println(System.currentTimeMillis()+"ms:redis消费了一个任务:消费的订单OrderId为"+orderId);
    }
}

修改后代码输出即为正常。

思路二

该方案使用redis的Keyspace Notifications,利用该机制可以在key失效之后,提供一个回调,实际上是redis会给客户端发送一个消息。值得注意的是redis版本要在2.8以上。

具体实现:

1)向redis.conf中,加入一条配置

notify-keyspace-events Ex

2)代码实现:

public class RedisTest {
    private static final String ADDR = "127.0.0.1";
    private static final int PORT = 6379;

    private static JedisPool jedis = new JedisPool(ADDR, PORT);
    private static RedisSub sub = new RedisSub();

    public static void init() {
        new Thread(new Runnable() {
            public void run() {
                jedis.getResource().subscribe(sub, "__keyevent@0__:expired");
            }
        }).start();
    }

    public static void main(String[] args) throws InterruptedException {
        init();

        for(int i =0;i<10;i++){
            String orderId = "OID000000"+i;
            jedis.getResource().setex(orderId, 3, orderId);
            System.out.println(System.currentTimeMillis()+"ms:"+orderId+"订单生成");
        }
    }

    static class RedisSub extends JedisPubSub {
        public void onMessage(String channel, String message) {
            System.out.println(System.currentTimeMillis()+"ms:"+message+"订单取消");
        }
    }
}

3)输出体现3秒过后,订单取消了

redis的pub/sub机制存在一个硬伤,官网内容如下:

Because Redis Pub/Sub is fire and forget currently there is no way to use this feature if your application demands reliable notification of events, that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.

直译过来的意思:

Redis的发布/订阅目前是即发即弃(fire and forget)模式的,因此无法实现事件的可靠通知。也就是说,如果发布/订阅的客户端断链之后又重连,则在客户端断链期间的所有事件都丢失了。

故,这个方案不太推荐使用。如你对可靠性要求不是很高时,可以使用。

优点:

(1)由于使用Redis作为消息通道,消息都存储在Redis中。如果发送程序或者任务处理程序挂了,重启之后,还有重新处理数据的可能性。

(2)做集群扩展相当方便

(3)时间准确度高

缺点:

需要额外进行redis维护

(5)使用消息队列

可以采用RabbitMQ的延时队列。RabbitMQ具有以下两个特性,可以实现延迟队列

RabbitMQ可以针对Queue和Message设置 x-message-tt,来控制消息的生存时间,如果超时,则消息变为dead letter

lRabbitMQ的Queue可以配置x-dead-letter-exchange 和x-dead-letter-routing-key(可选)两个参数,用来控制队列内出现了deadletter,则按照这两个参数重新路由。

优点: 

高效,可以利用rabbitmq的分布式特性轻易的进行横向扩展,消息支持持久化增加了可靠性。

缺点:

本身的易用度要依赖于rabbitMq的运维.因为要引用rabbitMq,所以复杂度和成本变高

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/329024.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

leetcode—矩阵

1 矩阵置零 给定一个 m x n 的矩阵&#xff0c;如果一个元素为 0 &#xff0c;则将其所在行和列的所有元素都设为 0 。请使用 原地 算法。 示例 1&#xff1a; 输入&#xff1a;matrix [[1,1,1],[1,0,1],[1,1,1]] 输出&#xff1a;[[1,0,1],[0,0,0],[1,0,1]] 方法一&#xf…

知识库建设教程来啦,赶紧收藏起来

播种知识&#xff0c;收获效率。知识库&#xff0c;这个企业内部服务的“大百科”&#xff0c;可能是你下一步需要建立的重要工具哦&#xff01;今天&#xff0c;就让我们一起来看一下如何进行知识库的建设和维护。 首先&#xff0c;让我们理解一下知识库的定义。知识库就像是一…

探索Python数据结构与算法:解锁编程的无限可能

文章目录 一、引言1.1 数据结构与算法对于编程的重要性1.2 Python作为实现数据结构与算法的强大工具 二、列表和元组2.1 列表&#xff1a;创建列表、索引、切片和常用操作2.2 元组&#xff1a;不可变序列的特性和使用场景 三、字符串操作和正则表达式3.1 字符串的常见操作和方法…

第36期 | GPTSecurity周报

GPTSecurity是一个涵盖了前沿学术研究和实践经验分享的社区&#xff0c;集成了生成预训练Transformer&#xff08;GPT&#xff09;、人工智能生成内容&#xff08;AIGC&#xff09;以及大型语言模型&#xff08;LLM&#xff09;等安全领域应用的知识。在这里&#xff0c;您可以…

c语言-库函数strstr()、strtok()、strerror()介绍

文章目录 前言一、库函数strstr()1.1 strstr()介绍1.2 strstr()模拟实现 二、库函数strtok()2.1 strtok()介绍 三、库函数strerror()3.1 strerror()介绍 总结 前言 本篇文章介绍c语言库函数strstr()、strtok()、strerror()的使用。 一、库函数strstr() 1.1 strstr()介绍 str…

Linux/Networked

Enumeration nmap 网站更新之后有了一个引导模式&#xff0c;更利于学习了&#xff0c;之前看ippsec的视频&#xff0c;要不总是没有思路&#xff0c;现在出现的问题多了提示也更多了&#xff0c;还没有使用&#xff0c;一会用用再说 首先&#xff0c;第一个问题是“目标上正…

RocketMQ源码阅读-Producer消息发送

RocketMQ源码阅读-Producer消息发送 1. 从单元测试入手2. 启动过程3. 同步消息发送过程4. 异步消息发送过程5. 小结 Producer是消息的生产者。 Producer和Consummer对Rocket来说都是Client&#xff0c;Server是Broker。 客户端在源码中是一个单独的Model&#xff0c;目录为rock…

WordPress后台仪表盘自定义添加删除概览项目插件Glance That

成功搭建WordPress站点&#xff0c;登录后台后可以在“仪表盘 – 概览”中看到包括多少篇文章、多少个页面、多少条评论和当前WordPress版本号及所使用的主题。具体如下图所示&#xff1a; 但是如果我们的WordPress站点还有自定义文章类型&#xff0c;也想在概览中显示出来应该…

《计算机视觉处理设计开发工程师》

计算机视觉&#xff08;Computer Vision&#xff09;是一门研究如何让计算机能够理解和分析数字图像或视频的学科。简单来说&#xff0c;计算机视觉的目标是让计算机能够像人类一样对视觉信息进行处理和理解。为实现这个目标&#xff0c;计算机视觉结合了图像处理、机器学习、模…

我的年终总结2023

As a DBA 从2023年初开始&#xff0c;我就给自己定下了23年的主要任务——学习PostgreSQL数据库。虽然没有定下细致的计划&#xff0c;但总体的目标是把PG的一些基础知识学完。后来发现我想简单了&#xff0c;学习PG的成本比我想象的多的多&#xff0c;导致23年这个目标没有完…

【CSP】2023年12月真题练习(更新到202312-2)

试题编号&#xff1a;202312-1试题名称&#xff1a;仓库规划时间限制&#xff1a;1.0s内存限制&#xff1a;512.0MB问题描述&#xff1a; 问题描述 西西艾弗岛上共有 n 个仓库&#xff0c;依次编号为 1⋯n。每个仓库均有一个 m 维向量的位置编码&#xff0c;用来表示仓库间的物…

汽车生产污废水处理需要哪些工艺设备

对于汽车生产过程中产生的污废水处理&#xff0c;需要运用一系列的工艺设备来实现有效的清洁和回收利用。下面让我们一起来探索一下吧&#xff01; 首先&#xff0c;汽车生产工艺设备中最常见的是物理处理设备。物理处理包括沉淀、过滤和吸附等过程。其中&#xff0c;沉淀操作可…

Angular系列教程之观察者模式和RxJS

文章目录 引言RxJS简介RxJS中的设计模式观察者模式迭代器模式 示例代码RxJS 在 Angular 中的应用总结 引言 在Angular开发中&#xff0c;我们经常需要处理异步操作&#xff0c;例如从后端获取数据或与用户的交互。为了更好地管理这些异步操作&#xff0c;Angular中引入了RxJS&…

Java、C#、Python间的Battle

一、编译原理和开发效率 编译速度&#xff1a; C# &#xff08;约大于等于&#xff09; JAVA > Python python的编译原理 前提&#xff1a;python 3.6 python不会直接编译源码 而是把源码直接扔给解释器&#xff0c;这种方式 使得python非常灵活&#xff0c;让它的开发效…

从零开始:生产环境如何部署 Bytebase

Bytebase 是面向研发和 DBA 的数据库 DevOps 和 CI/CD 协同平台。目前 Bytebase 在全球类似开源项目中 GitHub Star 数排名第一且增长最快。 Bytebase 的架构 Bytebase 是一个单体架构 (monolith)&#xff0c;前端是 Vue3 TypeScript&#xff0c;后端是 Go。前端利用 Go 1.6 …

好用的内外网快速传输大文件方法

在信息化时代&#xff0c;数据已经成为各行各业的关键资产&#xff0c;数据的传输和交换方式直接影响着数据价值的体现。在众多场景下&#xff0c;我们需要在不同的网络环境中进行文件传输&#xff0c;如同一个局域网内或者互联网上。这时涉及到内外网的概念。 内外网指的是在不…

UE5 nDisplay群集事件的发送和接收

注意&#xff1a; 1.只能在投屏模式下生效 2.需要监听的机器都要执行“1.打开监听”

创意无限!亲测可用的免费Photoshop素材网站大揭秘!

高质量的PS材料可以保证设计师设计作品的质量&#xff0c;但很多人不知道在哪里找到一些免费的材料&#xff0c;尤其是对初学者来说。那么&#xff0c;有没有质量好、免费的PS材料网站呢&#xff1f;别担心&#xff0c;现在就告诉你。 即时设计 被很多人视为免费的PS素材网站…

likeshop知识付费系统PHP版v1.4.0

✅ 新增功能 题库功能 ⚡ 功能优化 数据库检测优化 订单中心页优化 系统-登录时效优化 &#x1f41e; 功能修复 详情页佣金可见设置未生效 更新内容说明 1.题库 题库功能的引入&#xff0c;不仅仅是对学习方式的一次革新&#xff0c;更是为广大用户提供了更多更丰富的学…

【运维】WSL1如何升级到WSL2

升级WSL1到WSL2&#xff1a;简便快捷版 在这篇博客中&#xff0c;我们将研究如何通过一种更简便的方式&#xff0c;将WSL1迅速升级到WSL2&#xff0c;避免官方文档的繁冗步骤。如果你觉得官方方法太过冗长&#xff0c;那么这里提供的步骤可能更适合你。 官网的办法是&#xf…