消息队列

DLX Dead Letter Exchange 的缩写 DLX也叫死信邮箱（网上的译法），死信交换机（字面翻译）。归根结底就是一个交换机，当队列中出现死信时，通过这个交换机将死信重新发送到死信队列中（指定好rabbitmq会自动发送）。 什么是死信 什么是死信呢？官方给出三个说法： 消息被拒绝（basic.reject或basic.nack）并且requeue=false. 消息TTL过期 队列达到最大长度（队列满了，无法再添加数据到mq中） 什么是死信交换机 在定义业务队列的时候，要考虑指定一个死信交换机，死信交换机可以和任何一个普通的队列进行绑定，然后在业务队列出现死信的时候就会将数据发送到死信队列。 什么是死信队列 死信队列实际上就是一个普通的队列，只是这个队列跟死信交换机进行了绑定，用来存放死信而已。 如何使用死信交换机 #####定义业务（普通）队列的时候指定参数 x-dead-letter-exchange : 用来设置死信后发送的交换机 x-dead-letter-routing-key ：用来设置死信的routingKey 死信交换机图解 ![![ ] 创建业务队列 @Bean public Queue mailQueue() { Map<String, Object> map = new HashMap<String, Object>(); map.put("x

定时任务,在很多业务场景中都会存在.一般,我们简单解决的话,就是使用数据库来存储数据供服务端周期获取执行.显然,对于数据库处理,如果多线程或者多机器处理,就会存在扩展的问题.比如:现在一个任务记录到时间了需要执行,同时被多个executor抓取来执行,就会浪费不必要的资源;并且,这种场景还非常常见. 因此, 需要额外状态处理,或者其他分库分表策略保证尽量一个executor来操作一个记录,并且如果executor失败了,其他的executor才会去执行分配给失败executor的任务. 整个设计相对而言,就相当复杂了. 基于上面的一些原因,这里我们设计了一个简单的基于kafka消息队列的定时任务方案. 这里，首先定义一下定时消息。所谓定时消息，就是业务方根据自己的业务需求，指定在接下来的大概某个时间点来发送某条消息，从而保证该消息在某个时间点之后可接受的时间区间内消费该消息。所以这里需要指出： Note: 消息机制都是异步的，所以如果存在大量消息累积未消费，则无法保证定时消息指定的时间区间。因此，使用的时候，必须预计定时消息服务提供的服务能否满足业务的QPS要求。定时消息服务设计保证支持水平扩展，因此，可以根据业务性能需求，部署足够的服务。 kafka消息队列，所有触发都是基于消息机制的。所以，定时任务的设计必须要有定时消息服务来提供基础核心功能。首先

前言： ActiveMQ和 RabbitMq 以及Kafka在之前的项目中都有陆续使用过，当然对于三者没有进行过具体的对比，以下摘抄了一些网上关于这三者的对比情况，我自己看过之后感觉还 是可以的，比较清晰的反馈了这三个的具体情况已经使用场景，具体的对比如下： 1)TPS比较： Kafka最高，RabbitMq 次之， ActiveMq 最差。 2)吞吐量对比： kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。 rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。 3)在架构模型方面： RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。 kafka遵从一般的MQ结构

在Windows应用程序中，窗体是由一种称为“UI线程（User Interface Thread）”的特殊类型的线程创建的。 首先，UI线程是一种“线程”，所以它具有一个线程应该具有的所有特征，比如有一个线程函数和一个线程ID。 其次，“UI线程”又是“特殊”的，这是因为UI线程的线程函数中会创建一种特殊的对象——窗体，同时，还一并负责创建窗体上的各种控件。 每个UI线程都有一个消息队列，而不是每个窗体一个消息队列！ 只有当一个线程调用Win32 API中的GDI（Graphics Device Interface）和User函数时，操作系统才会将其看成是一个UI线程，并为它创建一个消息队列。 需要注意的是， 消息循环是由UI线程的线程函数启动的（如果函数线程 没有实现消息循环函数就不能处理消息，这个概念要牢记。只产生了一个窗口，但是没有消息处理函数，窗口就无法处理消息） ，操作系统不管这件事，它只管为UI线程创建消息队列 。因此，如果某个UI线程的线程函数中没有定义消息循环，那么，它所拥有的窗体是无法正确绘制的。 如果一个线程创建了窗口，拥有GUI资源，那么也称该线程为GUI线程 ,否则就为工作线程。 创建窗口的线程就拥有该窗口 。这种线程拥有关系的概念对窗口有重要的意义：建立窗口的线程必须是为窗口处理所有消息的线程。为了使这个概念更加明确具体，可以想像 一个线程建立了一个窗口

Fanout交换器特点： 各个队列与Topic交换器之间没有路由键绑定配置，发送者发送一条消息给交换器， 只要与此交换器绑定的队列，都会接收到消息。 生产者module，只需要指定交换器，发送消息也只需要指定交换器即可 pom.xml导入RabbitMQ坐标 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> application.properties配置RabbitMQ信息 #RabbitMQ基本信息 spring.rabbitmq.host=182.61.40.184 spring.rabbitmq.port=5672 spring.rabbitmq.username=rabbitmq spring.rabbitmq.password=rabbitmq #自定义配置 #设置交换器名称 spring.rabbitmq.exchange.name=fanoutExchange 创建Controller，通过浏览器请求，发送消息到RabbitMQ @Controller public class RabbitMQController { @Autowired private

Topic交换器特点： 各个队列与Topic交换器之间的路由键配置 模糊 ，发送者发送一条消息，只要 路由键符合规则 的队列就能接收到消息。 创建消息生产者module：配置交换器名称和路由键信息。消息发送时，需要指定交换器和路由键。 pom.xml导入RabbitMQ坐标 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> application.properties配置RabbitMQ信息 #RabbitMQ基本信息 spring.rabbitmq.host=182.61.40.184 spring.rabbitmq.port=5672 spring.rabbitmq.username=rabbitmq spring.rabbitmq.password=rabbitmq #自定义配置 #设置交换器名称 spring.rabbitmq.exchange=topicExchange #设置路由键 user.log.info spring.rabbitmq.routingkey.user.info=user.log.info #设置路由键 user.log.error spring

什么是 MQ Message Queue（MQ），消息队列中间件。 很多人都说： MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。 MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。 一个分布式系统中两个模块之间通讯要么是 HTTP，要么是自己开发的 TCP，但是这两种协议其实都是原始的协议。 HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上 WebServer，而且还不支持长连接（HTTP 2.0 的库根本找不到）。 TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。 MQ 所要做的就是在这些协议之上构建一个简单的“协议”—— 生产者/消费者模型。 MQ 带给我的“协议”不是具体的通讯协议，而是更高层次 通讯模型 。 它定义了两个对象——发送数据的叫生产者，接收数据的叫消费者； 提供一个 SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议。 分类： MQ，分为有Broker的MQ，和没有Broker的MQ。 Broker，代理，经纪人的意思。 无Broker的MQ 无 Broker 的 MQ 的代表是 ZeroMQ。 有Broker的MQ

基本概念 Broker 容器: 它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输, 关系 “exchange”接收发布应用程序发送的消息，并根据一定的规则将这些消息路由到“消息队列”。 “message queue”存储消息，直到这些消息被消费者安全处理完为止。 “binding”定义了exchange和message queue之间的关联，提供路由规则。 Exchange 和 Routing_Key 交换器，根据类型自带规则，一般和Queue配合。 Exchange的类型表格： 类型 名称xxxxxxxxx 描述 Direct Exchange 直接匹配 通过Exchange名称+RountingKey来发送与接收消息. Fanout Exchange 广播订阅 向所有的消费者发布消息,但是只有消费者将队列绑定到该路由器才能收到消息,忽略Routing Key. Topic Exchange 主题订阅 根据Routing_Key的规则匹配消息，可以使用通配符： * 匹配任意单词 # 匹配单个或多个单词 Headers Exchange 消息头订阅 用的不多，略 Queue 队列，也就是消息载体 Queue 和 AnonymousQueue 的区别 都是Queue的2种实现。 Queue默认值： durable : true #

你好，世界 介绍 RabbitMQ是消息代理: 它接收并转发信息。举个例子： 小明从淘宝买了商品，配送员将快递投递到了快递柜， 小明再根据取件码去快递柜取快递。快递柜就相当于消息队列，快递员是生产者，小明是消费者。 生产者意味着发送， 所以发送信息的程序是生产者(Producer)。 尽管消息流经RabbitMQ和您的应用程序之中，但它们只能存储在队列之中， 甲队列仅由主机的存储器和磁盘限制和约束， 它本质上是一个大的消息缓冲器。许多生产者可以发送消息到同一个队列中，许多消费者可以尝试从一个队列中接收数据, 表示队列的方式。 消费与接收有相似的含义。消费者是一个程序，主要是等待接收信息。 生产者，消费者，消息队列不必位于同一主机上。一个应用程序既可以是消费者，也可以是生产者。 你好， 世界! 本部分内容中， 使用python编写两个小程序， 分别实现生产者和消费者。生产者进行数据发送，消费者进行数据接收并将其打印出来。 如图, P是生产者, 红色矩形相等于消息队列， C是消费者。 生产者将 hello 发送到队列中， 消费者从队列中接收 hello 。 RabbitMQ库 RabbitMQ使用多种协议。本教程使用AMQP 0-9-1，这是一种开放的通用消息传递协议。RabbitMQ有 许多不同语言 的客户。在本教程系列中，我们将使用 Pika 1.0.0

在 Invoke 或者 BeginInvoke 的使用中无一例外地使用了委托 Delegate ，至于委托的本质请参考我的另一随笔： 对 .net 事件的看法 。 一、为什么 Control 类提供了 Invoke 和 BeginInvoke 机制？ 关于这个问题的最主要的原因已经是 dotnet 程序员众所周知的，我在此费点笔墨再次记录到自己的日志，以便日后提醒一下自己。 1 、 windows 程序消息机制 Windows GUI 程序是基于消息机制的，有个主线程维护着一个消息泵。这个消息泵让 windows 程序生生不息。 Windows GUI 程序的消息循环 Windows 程序有个消息队列，窗体上的所有消息是这个队列里面消息的最主要来源。这里的 while 循环使用了 GetMessage （）这个方法，这是个阻塞方法，也就是队列为空时方法就会被阻塞，从而这个 while 循环停止运动，这避免了一个程序把 cpu 无缘无故地耗尽，让其它程序难以得到响应。当然在某些需要 cpu 最大限度运动的程序里面就可以使用另外的方法，例如某些 3d 游戏或者及时战略游戏中，一般会使用 PeekMessage （）这个方法，它不会被 windows 阻塞，从而保证整个游戏的流畅和比较高的帧速。 这个主线程维护着整个窗体以及上面的子控件。当它得到一个消息，就会调用