订单过期30分钟,不支付自动取消方案
最简单,粗暴的办法。开个任务,每3分钟扫描一次数据库
select orderid from table where ....
服务器开启crontab 定时扫描
优点:容易实现,支持集群服务
缺点:
1. 服务器消耗大
2. 存在延迟,并不是精确的3分钟
3. 如果订单量很大,比如1000万条没有付款,数据库压力很大
DelayQueue
优点:效率高,任务触发时间延迟低。
缺点:
(1)服务器重启后,数据全部消失,怕宕机
(2)集群扩展相当麻烦
(3)因为内存条件限制的原因,比如下单未付款的订单数太多,那么很容易就出现异常
(4)代码复杂度较高
利用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维护
我们可以采用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