订单过期30分钟，不支付自动取消方案

发表于 2021-12-13 09:14:18 by 月小升

订单过期30分钟，不支付自动取消方案

1. 扫描数据库

最简单，粗暴的办法。开个任务，每3分钟扫描一次数据库

select orderid from table where ....

服务器开启crontab 定时扫描

优点：容易实现，支持集群服务

缺点：
1. 服务器消耗大
2. 存在延迟，并不是精确的3分钟
3. 如果订单量很大，比如1000万条没有付款，数据库压力很大

2. JDK延迟队列

DelayQueue

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

缺点:

(1)服务器重启后，数据全部消失，怕宕机
(2)集群扩展相当麻烦
(3)因为内存条件限制的原因，比如下单未付款的订单数太多，那么很容易就出现异常
(4)代码复杂度较高

3. Redis 缓存

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

zset常用命令

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

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

查询元素score:ZSCORE key member

移除元素:ZREM key member [member …]
# 添加单个元素

redis> ZADD page_rank 10 google.com
(integer) 1
 
# 添加多个元素
 
redis> ZADD page_rank 9 baidu.com 8 bing.com
(integer) 2
 
 ## 查询全部数据
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"
5) "google.com"
6) "10"
 
# 查询元素的score值
redis> ZSCORE page_rank bing.com
"8"

 
# 移除单个元素
 
redis> ZREM page_rank google.com
(integer) 1
 
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"

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

zadd OrderId 999 OID01
zadd OrderId 997 OID02
zadd OrderId 998 OID03

// zadd OrderId 999 OID01 997 OID02 998 OID03

// 读取全部订单
ZRANGE OrderId 0 -1 WITHSCORES

// 只读一个订单，得分最小的那个，就是时间最早的那个订单。
ZRANGE OrderId 0 0 WITHSCORES

Zrange 查询得分最小的订单每500MS 扫描一次redis进行处理

package com.javaer.Redis;
import java.util.Calendar;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Tuple;
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);
            System.out.println(second3later);
            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 items = jedis.zrangeWithScores("OrderId", 0, 0);
            //System.out.println(items.toArray().length);
            //System.exit(0);
            if(items == null || items.isEmpty()){
                System.out.println("当前没有等待的任务");
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    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();
    }
}

然而，这一版存在一个致命的硬伤，在高并发条件下，多消费者会取到同一个订单号，我们上测试代码ThreadTest
并发消费订单java代码

package com.javaer.Redis;
import java.util.concurrent.CountDownLatch;
public class ThreadApp {
	private static final int threadNum = 10;
    private static CountDownLatch cdl = new CountDownLatch(threadNum);
    static class DelayMessage implements Runnable{
        public void run() {
            try {
                cdl.await();
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            AppTest appTest =new AppTest();
            appTest.consumerDelayMessage();
        }
    }
    public static void main(String[] args) {
        AppTest appTest =new AppTest();
        appTest.productionDelayMessage();
        for(int i=0;i<threadNum;i++){
            new Thread(new DelayMessage()).start();
            cdl.countDown();
        }
    }

}

运行结果

1639357729963ms:redis生成了一个订单任务：订单ID为OID00000010
1639357732
1639357729963ms:redis生成了一个订单任务：订单ID为OID00000011
1639357732
1639357729964ms:redis生成了一个订单任务：订单ID为OID00000012
1639357732
1639357729964ms:redis生成了一个订单任务：订单ID为OID00000013
1639357732
1639357729964ms:redis生成了一个订单任务：订单ID为OID00000014
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000014
1639357732000ms:redis消费了一个任务：消费的订单OrderId为OID00000014
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务

解决方案

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

(2)对ZREM的返回值进行判断，只有大于0的时候，才消费数据。如果ZREM不大于0，说明有别的线程处理了这个订单。

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

优点：

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

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

(3)时间准确度高

缺点:

(1)需要额外进行redis维护

4. 使用消息队列

我们可以采用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,所以复杂度和成本变高

https://www.cnblogs.com/cangqinglang/p/15188334.html

This entry was posted in JAVA, 数据库 and tagged redis, 值得记忆, 订单. Bookmark the permalink.

月小升QQ 2651044202, 技术交流QQ群 178491360

首发地址：月小升博客 – https://java-er.com/blog/order-30-time-cancel/
无特殊说明，文章均为月小升原创，欢迎转载，转载请注明本文地址，谢谢