在消息队列的最后一篇文章中，我们再来学习两个非常常见的队列功能。一个是延时队列，一个是优先级队列。它们的应用场景非常多，也非常有意思，不同的消息队列工具都提供了不同的实现，同样的，Redis 在 Laravel 框架中还是通过逻辑代码来实现类似功能的，非常值得大家来好好研究一下。
通过redis 有序集合来存储执行时间，每次取出第一个元素，执行时间与当前时间对比，如果小于等于当前时间则执行改脚本。并且移除改元素。 由于redis 集合具有唯一性，所以不能放在一个表里。
Redis 可以利用 zset (有序列表)来实现，将消息序列化成一个字符串作为 zset的 value； 这个消息的到期处理时间作为 score，利用多个线程轮询 zset 获取到期的任务进行处理。 多线程是为了保证可用性，万一挂了一个线程还有其他线程可以继续处理; 因为有多个线程，所以需要考虑并发争抢任务，确保任务不会多次执行。
作者：Amazing大龙大龙 链接：https://www.jianshu.com/p/a39904a0ba01 来源：简书
延迟队列，顾名思义它是一种带有延迟功能的消息队列。 那么，是在什么场景下我才需要这样的队列呢？
延迟队列，顾名思义它是一种带有延迟功能的消息队列。那么，是在什么场景下我才需要这样的队列呢？
背景：公司最早的一个版本的订单管理，是通过PHP+mysql的方案去实现的，这样会有什么问题呢，假设如果放到一个实例里面，全部用一个单机事务去解决，这样是能比较方便的解决数据一致性问题。但是存在两个问题，一是无法进行多实例部署，用户量增长以后，无法快速应对。二是，PHP中做事务，如果PHP遇到异常，有时并不会自动终止事务，导致DB被锁住，这是第一个版本。之后，我们推出了第二个版本V2，这个版本的时候，我们已经开发好了，库存管理系统，优惠券管理系统，PHP中，已经不直接通过DB去修改库存和优惠券，而是通过接口访问的方式去请求SERVER进行修改。这个版本，实际上已经从逻辑上，把订单系统和库存管理，优惠券管理系统已经独立出来了。数据层面已经可以独立部署，不再依赖一个单机事务去实现数据一致性功能了。但这个版本虽然解决了数据分布的问题，但同时引入了一个新的问题，就是数据在订单，库存，优惠券之间无法保证一致性。举个例子：下个订单，调用库存成功，锁定优惠券失败，生成订单失败。这时候就会导致优惠券数据不一致性情况出来，未下单的优惠券也被锁住了。有同事可能会问：订单如果创建失败，那直接回滚优惠券操作，即去解锁优惠券系统即可实现数据一致性。不错，很多时候，是可以这么操作，但如果你回滚的时候，失败了呢？你是继续在这等着直到成功，还是继续等着？呵呵。。
ckafka、TDMQ Pulsar版、TDMQ RocketMQ 版、TDMQ RabbitMQ 版和TDMQ CMQ 版功能上有啥区别
RabbitMQ是一款使用Erlang开发的开源消息队列。本文假设读者对RabbitMQ是什么已经有了基本的了解，如果你还不知道它是什么以及可以用来做什么，建议先从官网的 RabbitMQ Tutorials 入门教程开始学习。
上节课我们已经学习到了消息的持久化和确认相关的内容。但是，光有这些还不行，如果我们的消费者出现问题了，无法确认，或者直接报错产生异常了，这些消息要怎么处理呢？直接丢弃？这就是丢消息了呀。再次处理？一直继续报错怎么办？这条消息就永远都在不停报错的死循环中了。
Laravel 队列为不同的后台队列服务提供统一的 API，例如 Beanstalk，Amazon SQS，Redis，甚至其他基于关系型数据库的队列。队列的目的是将耗时的任务延时处理，比如发送邮件，从而大幅度缩短 Web 请求和响应的时间。
Beanstalk是一个基于内存的（binlog持久化到硬盘），事件驱动（libevent），简单、快速的任务队列，支持大部分编程语言，将前台的任务转为后台异步处理，为web开发提供更高弹性。它可以支持多个server（客户端支持），一个任务只会被投递到一台server，一个任务只会被一个消费者获取（Reverse）。
两者的区别在哪？ 异步相对于同步来说，页面非阻塞，减少了用户等待的时间体验相对来说比较好
概述 什么是队列？ 百度百科是这样说的 “队列”是在传输过程中保存数据的容器。 举几个生活中例子： * iphone手机新款发布，三里屯iphone进的新货。大家要排队买，不能说一大堆人一起
本文实例讲述了PHP使用ActiveMQ实现消息队列的方法。分享给大家供大家参考，具体如下：
配置使用数据库作为任务存储驱动 #config/queue.php文件中 'default' => env('QUEUE_CONNECTION', 'sync'),默认是同步。 QUEUE_CONNECTION对应.env中的QUEUE_CONNECTION 我们修改.env文件使用mysql数据库作为驱动：QUEUE_CONNECTION=database 数据迁移（驱动的必要设置）说白了就是创建存储队列任务的数据表 #在database/migrations文件夹下面生成迁移文件 xxxx_xx_x
2、针对客户端发来的数据，做自己的标准，达到类似URL的module、controller、method、params等效果
Laravel 队列为不同的后台队列服务提供统一的 API，例如 Beanstalk，Amazon SQS，Redis，甚至其他基于关系型数据库的队列。队列的目的是将耗时的任务延时处理，比如发送邮件，从而大幅度缩短 Web 请求和相应的时间。
顾名思义，延迟队列就是进入该队列的消息会被延迟消费的队列。而一般的队列，消息一旦入队了之后就会被消费者马上消费。
讲一下我们公司的业务吧。 我们公司是当前市面上最火热，最热辣的O2O。为了解决这一块问题，我们公司针对附近3.5KM的任务来进行派活。如果5分钟内，有附件的商家在接活这个活就是商家的。 如果附件的商家没有接活呢？这样用户体验不就很不好吗？所以说，我们有专门的派单的业务员。只要5分钟没人接的活，会有专门的跑腿 业务员来完成对应的工作。 所以，转换成技术语言就变成这样了： 用户派出一个活，通过IM（即时通信）系统发给商家。如果这个活被人接了，接单请求给到API。进入至交易状态。 如果这个活没有被人接，用户也没有
执行 5 中的程序，控制台监听到，便会后台自动 下载http://example.com/image.jpg到本地为/tmp/image.jpg
一个复杂的web系统后台当中，一定会有很多定时脚本或者任务要跑。例如爬虫系统需要定期去爬取一些网站数据，自动还贷系统需要每个月定时对用户账户扣款结算，会员系统需要定期检测用户剩余会员天数以便及时通知续费等等。Linux系统中内置的crontab一般被广泛地用于跑定时任务。其任务指令格式如下：
由于是集团后台，这样操作者就很多，但操作日志却是很关键的信息，必须得写入数据库，这样多用户写入，我们就得用到异步队列进行消费，防止写入失败，如果队列进行消费指定参数后还是失败，就得写入日志进行钉钉消息推送，具体可以看我另外一篇文章：
哈哈哈，说好的不卷了，能凑活用就行了。但每次接到新需求时都手痒，想结合着上一次的架构设计和落地经验，在这一次需求上在迭代更新，或者找到完全颠覆之前的更优方案。卷完代码的那一刻总是神清气爽
场景一：物联网系统经常会遇到向终端下发命令，如果命令一段时间没有应答，就需要设置成超时。
相信大家都很想取爬取某些网站的内容,图片,但是不知道怎么动手,以下的教程就是从0开始教大家爬取某个网站图片
在互联网后端日常开发接口的时候中，不管你使用的是C、Java、PHP还是Golang，都避免不了需要调用mysql、redis等组件来获取数据，可能还需要执行一些rpc远程调用，或者再调用一些其它restful api。 在这些调用的底层，基本都是在使用TCP协议进行传输。这是因为在传输层协议中，TCP协议具备可靠的连接，错误重传，拥塞控制等优点，所以目前应用比UDP更广泛一些。 相信你也一定听闻过TCP也存在一些缺点，那就是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小，而少见不给出具体的量化分析。不客气一点，这都是营养不大的废话。经过日常工作的思考之后，我更想弄明白的是，开销到底多大。一条TCP连接的建立需要耗时延迟多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化估计？当然影响TCP耗时的因素有很多，比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。
我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。
因为工作中需要用到分布式的延时队列，调研了一段时间，选择使用 Redisson DelayedQueue，为了搞清楚内部运行流程，特记录下来。
地址：www.cnblogs.com/xiaowei123/p/13222710.html
延时队列：顾名思义，是一个用于做消息延时消费的队列。但是它也是一个普通队列，所以它具备普通队列的特性，相比之下，延时的特性就是它最大的特点。所谓的延时就是将我们需要的消息，延迟多久之后被消费。普通队列是即时消费的，延时队列是根据延时时间，多久之后才能消费的。
MQ全称 Message Queue（消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。
虽然 reuse port 是在 linux 3.9 才被合并进来，但有 backport 到更早之前的版本（至少我们在使用的 2.6.32 是有的），很多博客在这点上有些误导。另外，在 reload 时候也不能简单将老的监听关闭，会导致 tcp backlog 里面这些三次握手成功但未 accept 的连接丢失，业务在这些连接上发送数据则会收到 rst 包。
但是我还想到一种方案就是使用 Redis 的键空间通知（keyspace notification）。意思就是当 Redis 的 key 删除是，回主动通知发送消息给我们，我们只需要监听订阅对应的事件即可。
今天使用 jQuery 的 delay() 来延迟执行 hide() ，发现延时不起效，查了一些资料，找到了其中的原因。
同步请求：在用户进行请求发送之后，浏览器会一直等待服务器的数据返回，如果网络延迟比较高，浏览器就一直卡在当前界面，直到服务器返回数据才可进行其他操作。
通常我们使用Handler的消息延时都是调用sendMessageDelayed函数实现的，其中delayMillis是需要延时的毫秒。
在上一篇中，介绍了RabbitMQ中的死信队列是什么，何时使用以及如何使用RabbitMQ的死信队列。相信通过上一篇的学习，对于死信队列已经有了更多的了解，这一篇的内容也跟死信队列息息相关，如果你还不了解死信队列，那么建议你先进行上一篇文章的阅读。
—1— 前言 延时消息（定时消息）指的在分布式异步消息场景下，生产端发送一条消息，希望在指定延时或者指定时间点被消费端消费到，而不是立刻被消费。 延时消息适用的业务场景非常的广泛，在分布式系统环境下，延时消息的功能一般会在下沉到中间件层，通常是 MQ 中内置这个功能或者内聚成一个公共基础服务。 本文旨在探讨常见延时消息的实现方案以及方案设计的优缺点。 —2— 实现方案 1. 基于外部存储实现的方案 这里讨论的外部存储指的是在 MQ 本身自带的存储以外又引入的其他的存储系统。 基于外部存储的方案本质上都是
DelayQueue 是BlockingQueue接口的实现类，它根据"延时时间"来确定队列内的元素的处理优先级（即根据队列元素的“延时时间”进行排序）。另一层含义是只有那些超过“延时时间”的元素才能从队列里面被拿出来进行处理。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
延时消息（定时消息）指的在分布式异步消息场景下，生产端发送一条消息，希望在指定延时或者指定时间点被消费端消费到，而不是立刻被消费。
上篇文章介绍了RocketMQ整体架构和原理有兴趣的可以阅读一下，在这篇文章中的延时消息部分，我写道开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。
rabbitmq 是目前使用最为普及的消息队列组件，基于 AMQP 的 rabbitmq 在各方面设计都比较完善，同时，它具有非常丰富的功能与特性，可以支持各种实际的适用场景。 但是 rabbitmq 本身并不直接支持延时队列的功能，本文我们就来介绍一下，如何通过 rabbitmq 的特性实现一个延时队列。
MQ是消息服务中间件，基于高可用分布式集群技术，是消费模式基于发布订阅模式的消息系统。支持Java，C++以及.NET，PHP，Python，为分布式应用系统提供异步解耦、削峰填谷的能力，具备海量消息堆积、高吞吐、可靠重试等特性。具有消息查询，消息回溯(不是消息撤回，也不支持消息撤回)，消息轨迹查询，堆积监控报警功能。 MQ协议支持接入方式 : TCP、HTTP(RESTful 风格)、MQTT。MQ支持公网访问，但可用性较低。 MQ应用场景 : 分布式事务，物联网应用，实时计算(将产生的数据实时流入到实时计算引擎来实现)，同步大规模缓存。 实时计算引擎一般有 : Spark / Storm / EMR / ARMS / BeamRunner。 MQ拥有管理工具 : Web控制台，Open API，mqadmin命令集。拥有微消息队列(LMQ)，RocketMQ消息队列，Kafka消息队列，跨域中继服务(CRS)等组件。 Web控制台提供消息查询、消息轨迹查询、重置消费位点、资源统计、监控报警等操作。消息查询有三种方式 :** 根据Message ID(精确查询)，Message Key(模糊查询)以及Topic查询(范围查询)，HTTP消息目前只支持Message ID和Topic两种查询方式。** 消息轨迹查询只支持TCP和HTTP协议，可追踪消息从生产者发出到消费者消费的整个链路中各个相关节点的时间地点。 重置消费位点可跳过堆积的消息，即不想消费这部分消息，或者只想消费某个时间点后的消息（这些消息不论之前是否消费过）。 资源报表可对消息发送和消息消费的数据进行统计，暂不支持HTTP消费数据的统计查询。 监控报警一般用在消息堆积数或者延迟时间超过阈值之后，对报警接收人发送短信，如果发现消息堆积很多，可检查阈值是否设置过小导致消息堆积，可调整业务代码或者对消费者进行扩容，可使用jstack查看是否消费线程阻塞。 微消息队列(LMQ)基于MQTT(Message Queuing Telemetry Transport 消息队列遥测传输)协议，标准协议端口为1883，支持加密SSL，WebSocket，Flash接入方式。协议重要部分主要分为 : MQ Core Service(负责底层的消息存储和分发)，MQ私有协议服务器以及MQTT协议网关服务器(负责对客户端提供服务和协议转换)。主要使用场景有 : 直播互动、车联网、金融支付、即时聊天等。协议相关 : QoS(Quality of Service)指代消息传输的服务质量。它包括QoS0(最多分发一次)、QoS1(至少达到一次)和QoS2(仅分发一次)三种级别。cleanSession标识客户端建立TCP连接后是否关心之前状态(true or false)。 MQTT可进行实例管理(查看消息收发TPS、同时在线连接数、订阅关系数等信息，可设置实例报警)，可申请MQTT Topic，可为Topic申请MQTT Group ID(一组逻辑功能完全一致的节点共用的组名，代表一类相同功能的设备，必须拥有Topic的读写权限)。可进行签名计算和签名生成。 MQTT可获取离线消息，可主动拉取离线消息，客户端每次拉取消息数量最多为30条，拉取请求的最大频率限制为5次/秒。离线消息优先级低，对其进行有限和最终能处理即可，要求比较实时。 MQTT可获取客户端上下线事件(上下线事件触发时，会向后端MQ推送一条上下线消息，通过订阅这条消息获取)，上下线事件类型一般放在MQ的Tag中，有三种状态 : connect(客户端上线)，disconnect(客户端主动断开连接)，tcpclean(实际的TCP连接断开)。tcpclean代表客户端网络层连接的真实断开，判断客户端下线请使用tcpclean事件。 MQTT通过Token鉴权服务向客户端提供访问权限。客户端需要采用MQTT控制报文以同步发送模式并且QoS必须为1，来上传Token。客户端应该对Token做好持久化，监听Proxy下推的Token失效的通知消息，Token失效必须重新申请。 LMQ的Topic，ClientId长度最大为64个字符，消息大小最大为64K，消息保存时间最长为3天，单个客户端订阅Topic数量最大为30个(超过该限制数量的Topic会被丢弃)，消息顺序性为上行顺序。 跨域中继服务(CRS，跨域哦，实现服务发布与订阅，实现不同网络的服务互通)提供三种MQ消息发送方式 :可靠同步发送(发出消息响应后才能发下一个消息，应用场景广，如重要通知邮件、报名短信通知、营销短信系统)，可靠异步发送(不需要等待响应即可发下一个消息，应用场景一般是耗时长，对RT响应敏感的业务，如视频上传后通知转码服务，转码后通知推送转码结果)，One Way(单向发送，不需要响应的方式，耗时超短，对可靠性要求不高的场
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
