前往小程序，Get更优阅读体验！
立即前往
文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布
首页
学习
活动
专区
圈层
工具
MCP广场
返回腾讯云官网
社区首页 >专栏 >实现订单 30 分钟未支付则自动取消，我有五种方案！

实现订单 30 分钟未支付则自动取消，我有五种方案！

作者头像
用户1220090
发布于 2025-05-08 06:15:43
发布于 2025-05-08 06:15:43
12900
代码可运行
举报
文章被收录于专栏：芋道源码芋道源码
运行总次数：0
代码可运行
关联问题
换一批

引言

在开发中，往往会遇到一些关于延时任务的需求。例如

  • 生成订单30分钟未支付，则自动取消
  • 生成订单60秒后,给用户发短信

对上述的任务，我们给一个专业的名字来形容，那就是延时任务 。那么这里就会产生一个问题，这个延时任务 和定时任务 的区别究竟在哪里呢？一共有如下几点区别

  1. 定时任务有明确的触发时间，延时任务没有
  2. 定时任务有执行周期，而延时任务在某事件触发后一段时间内执行，没有执行周期
  3. 定时任务一般执行的是批处理操作是多个任务，而延时任务一般是单个任务

下面，我们以判断订单是否超时为例，进行方案分析

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
  • 视频教程：https://doc.iocoder.cn/video/

方案分析

(1)数据库轮询

思路

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

实现

博主当年早期是用quartz来实现的(实习那会的事)，简单介绍一下 maven项目引入一个依赖如下所示

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
    <dependency>
    <groupId>org.quartz-scheduler</groupId>
    <artifactId>quartz</artifactId>
    <version>2.2.2</version>
</dependency>

调用Demo类MyJob如下所示

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay1;

import org.quartz.JobBuilder;
import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.SchedulerFactory;
import org.quartz.SimpleScheduleBuilder;
import org.quartz.Trigger;
import org.quartz.TriggerBuilder;
import org.quartz.impl.StdSchedulerFactory;
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;

public class MyJob implements Job {
    public void execute(JobExecutionContext context)
            throws JobExecutionException {
        System.out.println("要去数据库扫描啦。。。");
    }

    public static void main(String[] args) throws Exception {
        // 创建任务
        JobDetail jobDetail = JobBuilder.newJob(MyJob.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秒，输出如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
要去数据库扫描啦。。。
优缺点

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

缺点:

  • (1)对服务器内存消耗大
  • (2)存在延迟，比如你每隔3分钟扫描一次，那最坏的延迟时间就是3分钟
  • (3)假设你的订单有几千万条，每隔几分钟这样扫描一次，数据库损耗极大

(2)JDK的延迟队列

思路

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

DelayedQueue实现工作流程如下图所示

其中

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

定义一个类OrderDelay实现Delayed，代码如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay2;

import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;

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+"编号的订单要删除啦。。。。");
 }
}

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

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay2;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.DelayQueue;
import java.util.concurrent.TimeUnit;

public class DelayQueueDemo {
  public static void main(String[] args) {
         // TODO Auto-generated method stub
         List<String> list = new ArrayList<String>();
         list.add("00000001");
         list.add("00000002");
         list.add("00000003");
         list.add("00000004");
         list.add("00000005");
         DelayQueue<OrderDelay> queue = new DelayQueue<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) {
                 // TODO Auto-generated catch block
                 e.printStackTrace();
             }
         }
     }

}

输出如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
00000001编号的订单要删除啦。。。。
After 3003 MilliSeconds
00000002编号的订单要删除啦。。。。
After 6006 MilliSeconds
00000003编号的订单要删除啦。。。。
After 9006 MilliSeconds
00000004编号的订单要删除啦。。。。
After 12008 MilliSeconds
00000005编号的订单要删除啦。。。。
After 15009 MilliSeconds

可以看到都是延迟3秒，订单被删除

优缺点

优点:效率高,任务触发时间延迟低。 缺点:(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来实现 给Pom加上下面的依赖

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
  <dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-all</artifactId>
   <version>4.1.24.Final</version>
  </dependency>

测试代码HashedWheelTimerTest如下所示

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay3;

import io.netty.util.HashedWheelTimer;
import io.netty.util.Timeout;
import io.netty.util.Timer;
import io.netty.util.TimerTask;

import java.util.concurrent.TimeUnit;

public class HashedWheelTimerTest {
 static class MyTimerTask implements TimerTask{
  boolean flag;
  public MyTimerTask(boolean flag){
   this.flag = flag;
  }
  public void run(Timeout timeout) throws Exception {
   // TODO Auto-generated method stub
    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) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   }
         System.out.println(i+"秒过去了");
         i++;
        }
    }
}

输出如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
1秒过去了
2秒过去了
3秒过去了
4秒过去了
5秒过去了
要去数据库删除订单了。。。。
6秒过去了
优缺点

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

缺点:

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

(4)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 ...]

测试如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制

> 基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
>
> * 项目地址：<https://github.com/YunaiV/yudao-cloud>
> * 视频教程：<https://doc.iocoder.cn/video/>

# 添加单个元素

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,系统扫描第一个元素判断是否超时，具体如下图所示

实现一
代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay4;

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);
         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) {
     // 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();
 }
 
}

此时对应输出如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
1525086085261ms:redis生成了一个订单任务：订单ID为OID00000010
1525086085263ms:redis生成了一个订单任务：订单ID为OID00000011
1525086085266ms:redis生成了一个订单任务：订单ID为OID00000012
1525086085268ms:redis生成了一个订单任务：订单ID为OID00000013
1525086085270ms:redis生成了一个订单任务：订单ID为OID00000014
1525086088000ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525086088001ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525086088002ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525086088003ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525086088004ms:redis消费了一个任务：消费的订单OrderId为OID00000014
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务

可以看到，几乎都是3秒之后，消费订单。

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

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay4;

import java.util.concurrent.CountDownLatch;

public class ThreadTest {
 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();
  }
 }
}

输出如下所示

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
1525087157727ms:redis生成了一个订单任务：订单ID为OID00000010
1525087157734ms:redis生成了一个订单任务：订单ID为OID00000011
1525087157738ms:redis生成了一个订单任务：订单ID为OID00000012
1525087157747ms:redis生成了一个订单任务：订单ID为OID00000013
1525087157753ms:redis生成了一个订单任务：订单ID为OID00000014
1525087160009ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160011ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160012ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160022ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160023ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160029ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160038ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160045ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160048ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160053ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525087160064ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525087160065ms:redis消费了一个任务：消费的订单OrderId为OID00000014
1525087160069ms:redis消费了一个任务：消费的订单OrderId为OID00000014
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务

显然，出现了多个线程消费同一个资源的情况。

解决方案
  • (1)用分布式锁，但是用分布式锁，性能下降了，该方案不细说。
  • (2)对ZREM的返回值进行判断，只有大于0的时候，才消费数据，于是将consumerDelayMessage()方法里的
代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
if(nowSecond >= score){
 String orderId = ((Tuple)items.toArray()[0]).getElement();
 jedis.zrem("OrderId", orderId);
 System.out.println(System.currentTimeMillis()+"ms:redis消费了一个任务：消费的订单OrderId为"+orderId);
}

修改为

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
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);
 }
}

在这种修改后，重新运行ThreadTest类，发现输出正常了

思路二

该方案使用redis的Keyspace Notifications，中文翻译就是键空间机制，就是利用该机制可以在key失效之后，提供一个回调，实际上是redis会给客户端发送一个消息。是需要redis版本2.8以上。

实现二

在redis.conf中，加入一条配置

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
notify-keyspace-events Ex

运行代码如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
package com.rjzheng.delay5;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPubSub;

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 {
  @Override
  public void onMessage(String channel, String message) {
   System.out.println(System.currentTimeMillis()+"ms:"+message+"订单取消");
  }
 }
}

输出如下

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
1525096202813ms:OID0000000订单生成
1525096202818ms:OID0000001订单生成
1525096202824ms:OID0000002订单生成
1525096202826ms:OID0000003订单生成
1525096202830ms:OID0000004订单生成
1525096202834ms:OID0000005订单生成
1525096202839ms:OID0000006订单生成
1525096205819ms:OID0000000订单取消
1525096205920ms:OID0000005订单取消
1525096205920ms:OID0000004订单取消
1525096205920ms:OID0000001订单取消
1525096205920ms:OID0000003订单取消
1525096205920ms:OID0000006订单取消
1525096205920ms:OID0000002订单取消

可以明显看到3秒过后，订单取消了

ps: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)时间准确度高

缺点:(1)需要额外进行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,所以复杂度和成本变高

总结

本文总结了目前互联网中，绝大部分的延时任务的实现方案。希望大家在工作中能够有所收获。

其实大家在工作中，百分九十的人还是以业务逻辑为主，很少有机会能够进行方案设计。所以博主不推荐在分布式这块，花太多时间。不过，鉴于现在的面试造火箭，工作拧螺丝现象太过严重，所以，最后来个小漫画娱乐一下。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2025-05-07，如有侵权请联系 cloudcommunity@tencent.com 删除
数据库
redis
队列
集群
数据

本文分享自 芋道源码 微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ，欢迎热爱写作的你一起参与！

数据库
redis
队列
集群
数据
评论
登录后参与评论
暂无评论
登录 后参与评论
推荐阅读
实时视频传输中的BBR拥塞控制
编程算法gcc
在复杂的网络环境中，想要实现实时视频传输，拥塞控制算法是尤为重点的一环。本文整理自学霸君高级技术总监袁荣喜在LiveVideoStackCon 2019上海大会中的分享，详细介绍了BBR拥塞控制算法在实时视频传输中新的实践以及优缺点。
LiveVideoStack
2019/07/16
3.2K0
实时视频传输中的BBR拥塞控制
TCP拥塞控制及BBR原理分析
其他
导语：TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。本文介绍TCP发展过程中出现的几种拥塞控制算法，并着重介绍BBR的原理。
用户4141261
2018/12/07
15.1K0
BBR及其在实时音视频领域的应用
编程算法实时音视频gcc
大家好，我是网易云信音视频工程师肖磊，目前致力于实时音视频领域的QoS研究，通过优化拥塞控制算法，为用户提供高带宽利用率，低延时，抗抖动能力强的实时音视频服务。
LiveVideoStack
2019/10/15
2.4K0
一文解释清楚Google BBR拥塞控制算法原理
编程算法tcp/ip
BBR对TCP性能的提升是巨大的，它能更有效的使用当下网络环境，Youtube应用后在吞吐量上有平均4%提升（对于日本这样的网络环境有14%以上的提升）：
陶辉
2019/08/08
27.2K3
​TCP 拥塞控制详解
编程算法
作者：engleliu，腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法，内容多来自网上各个大佬的博客及《TCP/IP 详解》一书，在此基础上进行梳理总结，与大家分享。因水平有限，内容多有不足之处， 敬请谅解。 一、TCP 首部格式 在了解 TCP 的拥塞控制之前，先来看看 TCP 的首部格式和一些基本概念。 TCP 头部标准长度是 20 字节。包含源端口、目的端口、序列号、确认号、数据偏移、保留位、控制位、窗口大小、校验和、紧急指针、选项等。 TCP 首部格式 1.1 数据偏移（D
腾讯技术工程官方号
2020/06/01
3.3K0
WebRTC的拥塞控制和带宽策略
api实时音视频图像处理
在视频通信的技术领域WebRTC已成为主流的技术标准，WebRTC包涵了诸多优秀的技术，譬如：音频数字信号处理技术（AEC, NS, AGC）、编解码技术、实时传输技术、P2P技术等，这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中，通信时延、图像质量下降和丢包卡顿是经常发生的事，甚至在WiFi环境下，一次视频重发的网络风暴可以引起WiFi网络间歇性中断，通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。
LiveVideoStack
2021/09/01
1.5K0
直播弱网优化方法
云直播
直播平台纷繁杂多，流量入口逐渐从传统PC端过渡至移动端。直播规 模爆发式增长，2016年更是被誉为“直播元年”。以游戏为代表的泛娱乐直播是这一时期直播生态的重要组成部分。2015-2017年，4G技术普及，手机直播由于不受设备、场景等限制开始迅速普及，推动全民直播的出现；同时，由于直播功能的创新、直播平台以及资本的纷纷入局、政策支持，直播行业一度出现“千播大战”局面。期间，政府出台《电子竞技赛事管理暂行规定》等游戏行业相关政策，进一步推动了游戏直播的发展。
视频云直播helper
2022/02/03
6.1K1
Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现
腾讯云测试服务编程算法
原文 https://engineering.fb.com/video-engineering/copa/
LiveVideoStack
2019/11/26
1.6K0
Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现
技术解码 | 直播传输技术之SRT/WebRTC
api云直播电商
今年的双11格外疯狂，各大商家也纷纷开启了直播带货。为让广大消费者有更好的视听购物体验，腾讯视频云的小伙伴一刻也不敢放松，在做好全线护航的同时，还要保证低延迟高清流畅。随着用户对体验要求越来越高，直播进入了低延迟高码率的时代，直播传输技术也面临着越来越高的要求和挑战。 腾讯视频云为此在全链路上针对流媒体传输不断深入优化，使得在各大重要赛事上具备了高可靠、低延迟、高画质和音质的需求。下面就重点介绍其中应用的两个传输技术SRT和WebRTC。 传统TCP传输流媒体存在以下几个问题： (1) 在带宽受限
腾讯云音视频
2020/11/23
5K0
七牛云QRTC自研传输协议（QRTP）对音画质量的提升
udp七牛云协议
  //   编者按：自疫情开始席卷全球，人们对音视频的需求急剧上升。在需求上升的过程中，人们对网络延迟、音画质量的要求也在不断提高。LiveVideoStackCon 2022 音视频技术大会上海站有幸邀请到了七牛云资深开发工程师——于佳老师为我们讲述QRTN的网络架构是如何提升用户体验度的，以及分析其中的QRTP协议是如何对音画质量进行提升的。 文/于佳 整理/LiveVideoStack 大家好，我是于佳，来自七牛云开发团队，我今天给大家分享的主题是七牛云QRTC自研传输协议对音画质量的提升。今天的
LiveVideoStack
2022/08/26
4990
七牛云QRTC自研传输协议（QRTP）对音画质量的提升
长肥管道传输之痛与解决之道
缓存
随着腾讯云业务的全球扩张，越来越多的海外节点在陆续的建立起来，跨海，跨洲的长距离传输也越来越成为业务的常态（像直播视频云业务就有海外主播国内乃至全球观看的业务形态）。这种远距离的数据传输，拥有长的RTT(Round Trip Time往返时间)和高的带宽，管道容量（BDP，即Bandwidth和RTT的乘积）大，被称作长肥管道。传统的TCP应用于网络不稳定的长肥管道，传输效率不高，已越来越不能满足业务稳定高速传输的苛刻要求。本文分析了长肥管道存在的问题，并提出了解决此问题的一个思路。
glendai
2019/01/15
5.2K0
长肥管道传输之痛与解决之道
C|网络|TCP-BBR拥塞控制剖析
编程算法
传统TCP拥塞控制算法都是基于丢包的算法,例如收包加法增，丢包乘法减，然而基于丢包的算法无法达到理论的时延、带宽最优解。
朝闻君
2021/11/22
1.3K0
C|网络|TCP-BBR拥塞控制剖析
腾讯云音视频传输协议技术分析
云直播实时音视频api
导语 | 随着音视频应用的不断更新，对传输能力和体验的需求也日益增加，促进了传输技术的发展，也带了如何选择的难题。本文详解了音视频领域的几种主要传输协议,希望能够帮助大家解决实际需求和业务场景中的技术选型问题。 随着互联网的发展，Web及移动智能手机端的兴起，音视频应用也得到了蓬勃发展。同时伴随着4G/5G的商业化，人们在娱乐直播、购物、教育、医疗等领域，对于实时音视频通信的需求不断增长。直播、实时音视频等技术也开始崭露头角。 众多的音视频应用都避免不了一个问题就是，如何在现有的网络条件下，提
腾讯云音视频
2021/08/09
2.7K0
webRTC-NACK、Pacer和拥塞控制和FEC
api编程算法
2）NACK重新发送媒体数据有两种方式：单独RTX通道发送、与媒体数据混在一起发送
_咯噔_
2022/04/28
1.9K0
MMSys'2023 | 丢包网络多站点并行下载的 CUBIC 拥塞避免机制改进算法
事件视频数据算法网络
视频流媒体已经快速增长，并成为主要的互联网流量。实时视频流媒体使用户能够从各种提供商（如Netflix和YouTube）检索媒体内容，并使用户能够进行实时流媒体或视频通话。随着录制和显示技术的进步，立体和360度视频可能成为未来的另一个选择。除了观看，视频流还可以应用于将物理环境与扩展现实相结合，例如角色重建和物体检测
用户1324186
2023/10/28
4850
MMSys'2023 | 丢包网络多站点并行下载的 CUBIC 拥塞避免机制改进算法
有的放矢，远程操控中实时音视频的优化之道
5g实时音视频gcc缓存
在上一篇文章中，我们介绍了远程操控的技术要点。从这一章开始，笔者将会依次介绍远程操控三大技术的应用及优化重点内容。本文就将会以实时音视频通信技术开始，其主要被用于解决远程操控中被操控设备或车辆周边环境画面和声音向远处控制端的实时传输，方便远程驾驶员或操控员能够清晰地了解被控设备周遭情况，从而进行针对性操控。比如车辆前进中前方和侧后方的画面，挖掘机作业过程中的抓臂画面都需要通过实时音视频技术进行远程传输。
社区小番茄
2021/12/09
1.2K0
有的放矢，远程操控中实时音视频的优化之道
新一代直播传输协议SRT
编程算法unix云直播移动直播
SRT协议是基于UDT的传输协议，保留了UDT的核心思想和机制，抗丢包能力强，适用于复杂的网络。在LiveVideoStack线上分享中，新浪音视频架构师 施维对SRT协议的原理、优缺点特性以及在
LiveVideoStack
2020/03/06
3.2K0
新一代直播传输协议SRT
低延时实时音视频在5G远程操控场景的应用实践
5g实时互动-工业能源版自动驾驶无人驾驶实时音视频
  //   编者按：随着自动驾驶技术和5G行业应用的发展，5G远程实时操控类应用逐渐兴起，用于满足高危行业/恶劣场景远程作业、自动驾驶异常情况下远程介入等需求。相比直播、会议等传统实时音视频场景，由于操控的复杂性和车辆的移动性，远程实时操控对音视频传输的时延和可靠性提出了更高的要求。 本次分享将介绍5G远程实时操控行业应用场景对音视频传输的要求，以及腾讯云音视频针对5G远程实时操控场景的音视频传输优化和应用落地实践。 文/毛峻岭 整理/LiveVideoStack 我是来自腾讯的毛峻岭，今天很高兴能够给
LiveVideoStack
2022/08/26
1.1K0
低延时实时音视频在5G远程操控场景的应用实践
【杂谈】聊聊我们关于网络拥塞与控制优化的一些技术方案
编程算法缓存
互联网上的两点通信时，每经过一个路由设备叫一跳（Hop）。而每一跳都有不同的带宽，两点之间的可用带宽是每一跳中的最小值，被称为“Bottleneck BW”。
Yangsh888
2023/02/11
1.3K0
拥塞控制
编程算法性能测试腾讯云测试服务
本次演讲来自Demux-SF Video Technology July 2020，主讲者是Facebook的软件工程师Nitin Garg，介绍了怎样通过更好的拥塞控制进行更有效的传输，进而提高视频质量。
用户1324186
2020/10/21
1.5K0
推荐阅读
编辑精选文章
万字详解高可用架构设计Go 开发者必备：Protocol Buffers 入门指南10分钟带你彻底搞懂分布式链路跟踪多租户的 4 种常用方案亿级月活的社交 APP，陌陌如何做到 3 分钟定位故障？60页PPT全解：DeepSeek系列论文技术要点整理
相关讨论
实时音视频怎么控制时长？小程序多人实时音视频模板怎么控制显示视频数？实时音视频控制台概览？控制台指南文档？
相关课程
AI绘画-StableDiffusion图像生成微信小程序直播电商开发实践_《锋巢直播》Android
实时视频传输中的BBR拥塞控制
3.2K0
TCP拥塞控制及BBR原理分析
15.1K0
BBR及其在实时音视频领域的应用
2.4K0
一文解释清楚Google BBR拥塞控制算法原理
27.2K3
​TCP 拥塞控制详解
3.3K0
WebRTC的拥塞控制和带宽策略
1.5K0
直播弱网优化方法
6.1K1
Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现
1.6K0
技术解码 | 直播传输技术之SRT/WebRTC
5K0
七牛云QRTC自研传输协议（QRTP）对音画质量的提升
4990
长肥管道传输之痛与解决之道
5.2K0
C|网络|TCP-BBR拥塞控制剖析
1.3K0
腾讯云音视频传输协议技术分析
2.7K0
webRTC-NACK、Pacer和拥塞控制和FEC
1.9K0
MMSys'2023 | 丢包网络多站点并行下载的 CUBIC 拥塞避免机制改进算法
4850
有的放矢，远程操控中实时音视频的优化之道
1.2K0
新一代直播传输协议SRT
3.2K0
低延时实时音视频在5G远程操控场景的应用实践
1.1K0
【杂谈】聊聊我们关于网络拥塞与控制优化的一些技术方案
1.3K0
拥塞控制
1.5K0
相关推荐
实时视频传输中的BBR拥塞控制
更多 >
LiveVideoStack0
LV.3
这个人很懒，什么都没有留下～
文章
1.3K
获赞
4.2K
专栏
1
目录
  • 引言
  • 方案分析
    • (1)数据库轮询
      • 思路
      • 实现
      • 优缺点
    • (2)JDK的延迟队列
      • 思路
      • 实现
      • 优缺点
    • (3)时间轮算法
      • 思路
      • 实现
      • 优缺点
    • (4)redis缓存
      • 思路一
      • 实现一
      • 解决方案
      • 思路二
      • 实现二
      • 优缺点
    • (5)使用消息队列
      • 优缺点
  • 总结
加入讨论
的问答专区 >
不惑
1产品KOL擅长5个领域
相关课程
一站式学习中心 >
AI绘画-StableDiffusion图像生成
1698人在学
大模型图像创作引擎
高性能应用服务
微信小程序直播电商开发实践_《锋巢直播》
230人在学
Serverless 容器服务
云数据库 SQL Server
小程序·云直播
即时通信 IM
云直播
Android
164人在学
android
领券

腾讯云开发者

扫码关注腾讯云开发者

扫码关注腾讯云开发者

领取腾讯云代金券

热门产品

热门推荐

更多推荐

Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 

深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档

Copyright © 2013 - 2025 Tencent Cloud.

All Rights Reserved. 腾讯云 版权所有

登录 后参与评论
3