网上关于消息队列技术原理说明的详细文档很多,但涉及到Delphi的具体实现很少,这是我从网上找了一上午的资料,自己整合和尝试的能运行的程序. 打开控制面板->程序->添加组件,添加消息队列 打开控制面板->计算机管理->服务与应用程序->消息队列,添加私有有消息Test. 在Delphi中添加MSMQ控件, TMSMQMessage; TMSMQQueueInfo; TMSMQQueue; TMSMQEvent; 这些控件在Project->Import type Li

1. 前言 在阅读本文之前,可以查看微软官方的说明. https://www.azure.cn/documentation/articles/service-bus-create-queues/ 2. 介绍 1) service bus的队列,若当前消息被成功处理后,则这个消息会从队列中消失. 2) service bus是先进先出的队列,当取队列时,一直停留做等待,直到有消息进入. 3) Windows Azure Service Bus 提供安全且广泛可用的托管基础结构,以实现广泛通信.大范

在前面一章介绍了在.Net Core中如何使用RabbitMQ,至此入门的的部分就完成了,我们内心中一定还有很多疑问:如果多个消费者消费同一个队列怎么办?如果这几个消费者分任务的权重不同怎么办?怎么把同一个队列不同级别的任务分发给不同的消费者?如果消费者异常离线怎么办?不要着急,后面将慢慢解开面纱.我们将结合实际的应用场景来讲解更多的高级用法. 任务分发机制 设想如果把每个消息当做一个任务,生产者把任务发布到RabbitMQ,然后Consumer接收消息处理任务,如果我们发现一个Consumer

1.RabbitMQ介绍 RabbitMQ是实现AMQP(高级消息队列协议)的消息中间件的一种,最初起源于金融系统,用于在分布式系统中存储转发消息,在易用性.扩展性.高可用性等方面表现不俗.RabbitMQ主要是为了实现系统之间的双向解耦而实现的.当生产者大量产生数据时,消费者无法快速消费,那么需要一个中间层.保存这个数据. AMQP,即Advanced Message Queuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计.消息中间件主要用于组件

目录 定义的接口 接口实现 建立队列工厂 写入队列 获取消息 什么是MSMQ Message Queuing(MSMQ) 是微软开发的消息中间件,可应用于程序内部或程序之间的异步通信.主要的机制是:消息的发送者把自己想要发送的信息放入一个容器中(我们称之为Message),然后把它保存至一个系统公用空间的消息队列(Message Queue)中:本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理.下图展示了这一流程 MSMQ队列是一个可持久的队列,因此不必担心不间断地插入队列会导致

1.使用消息队列 消息队列函数: 函数名 功能 OSQCreate() 创建一个消息队列 OSQDel() 删除一个消息队列 OSQFlush() 清空一个消息队列 OSQPend() 任务等待消息 OSQPendAbort() 任务被不再等待该消息 OSQPost() 提交一个消息给消息队列 任务中消息队列函数: 函数名 功能 OSTaskQPend() 等待一个消息 OSTaskQPendAbort() 任务被不再等待该消息 OSTaskQPost() 发送一个消息给任务 OSTaskQFl

上一篇最后提到了mandatory这个参数,对于设置mandatory参数个人感觉还是很重要的,尤其在RabbitMQ镜像队列发生故障转移时. 模拟个测试环境如下: 首先在集群队列中增加两个镜像队列的策略: 对于ha-promote-on-shutdown这个参数,可以参考文档,其作用就是当集群中master出现故障时强制进行故障转移从而选出新的master节点,这里的master出现故障表示的是人为的故障比如通过命令行rabbitmqctl.bat start_app之类的关闭RabbitMQ

1. 路由: 前面的示例中,我们或得到的消息为广播消息,但是无法更精确的获取消息的子集,比如:日志消息,worker1只需要error级别的日志, 而worker2需要info,warning,error..等级别的全部日志,这时候就需要使用路由来标记队列接收何种类型的消息. 2. 绑定带路由的队列和交换: 在绑定队列和交换的时候,我们需要制定routing_key路由字段,标记队列需要接收何种消息,方式如下: channel.queue_bind(exchange=exchange_name,

一.为什么选择RocketMQ消息队列? 首先RocketMQ是阿里巴巴自研出来的,也已开源.其性能和稳定性从双11就能看出来,借用阿里的一句官方介绍:历年双 11 购物狂欢节零点千万级 TPS.万亿级数据洪峰,创造了全球最大的业务消息并发以及流转纪录(日志类消息除外): 在始终保证高性能前提下,支持亿级消息堆积,不影响集群的正常服务,在削峰填谷(蓄洪).微服务解耦的场景下尤为重要:这,就能说明RocketMQ的强大. 二.RocketMQ的特点和优势(可跳过看三的整合代码) 削峰填谷(主要解决

1.引入maven依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency>2.在application.yml的配置: spring: rabbitmq: host: 106.52.82.241 port: 5672 username: yang

除了同步方式的调用之外,有时还需要异步调用,用来处理不需要即时处理的信息,例如短信.邮件等,这需要使用EJB中的独特组件——消息驱动Bean(Message-Driven Bean,MDB),它提供了Java消息服务JMS(Java Messaging Service)的处理能力,由消息驱动Bean来处理JMS消息.JMS的消息由客户端程序产生,并被发布到服务器的消息队列,消息驱动Bean随之检索消息并执行其内容.这种事件或者数据的通信就称为异步形式,客户端或者服务端Bean都无须依赖对方的直接

1,回调函数工作机制 回调函数由操作系统自动调用,回调函数的返回值当然也是返回给操作系统了. 2,截获操作系统发出的消息,截获到后,将另外一个消息返回给操作系统,已达到欺骗操作系统的目的. 下面还是以具体例子来说明比较好. 在 Windows下,每一个鼠标消息都是由 WM_NCHITTEST 消息产生的,这个消息的参数包含了鼠标位置的信息.通常情况下,要把这个消息直接交给 DefWindowProc 函数处理,该函数会返回一个值来告诉 Windows 鼠标按下的是窗口的哪一部分.Windows

上节已经梳理了RocketMQ发送事务消息的流程(基于二阶段提交),本节将继续深入学习事务状态消息回查,我们知道,第一次提交到消息服务器时消息的主题被替换为RMQ_SYS_TRANS_HALF_TOPIC,本地事务执行完后如果返回本地事务状态为UN_KNOW时,第二次提交到服务器时将不会做任何操作,也就是说此时消息还存在与RMQ_SYS_TRANS_HALF_TOPIC主题中,并不能被消息消费者消费,那这些消息最终如何被提交或回滚呢? 原来RocketMQ使用TransactionalMessa

继续上篇文章解决RabbitMQ消息丢失问题和保证消息可靠性(一) 未完成部分,我们聊聊MQ Server端的高可用和消费端如何保证消息不丢的问题? 回归上篇的内容,我们知道消息从生产端到服务端,为了保证消息不丢,我们必须做哪些事情? 发送端采用Confirm模式,注意Server端没成功通知发送端,需要重发操作需要额外处理 消息的持久化处理 上面两个操作保证消息到服务端不丢,但是非高可用状态,如果节点挂掉,服务暂时不可用,需要重启后,消息恢复,消息不会丢失,因为有磁盘存储. 本文先从消费端讲起

在Invoke或者BeginInvoke的使用中无一例外地使用了委托Delegate,至于委托的本质请参考我的另一随笔:对.net事件的看法. 一.为什么Control类提供了Invoke和BeginInvoke机制? 关于这个问题的最主要的原因已经是dotnet程序员众所周知的,我在此费点笔墨再次记录到自己的日志,以便日后提醒一下自己. 1.windows程序消息机制 Windows GUI程序是基于消息机制的,有个主线程维护着一个消息泵.这个消息泵让windows程序生生不息. Window

原文链接(作者一个人):https://juejin.im/post/5d468591f265da03b810427e 工作中经常用到消息中间件来解决系统间的解耦问题或者高并发消峰问题,但是消息的可靠性如何保证一直是个很大的问题,什么情况下消息就不见了?如何防止消息丢失?下面通过这篇文章,我们就聊聊RabbitMQ 消息可靠性如何解决的? 本文分三部分说明 RabbitMQ 消息丢失场景有哪些? 如何避免消息丢失? 如何设计部署消息中间件保证消息可靠性? RabbitMQ 消息丢失场景有哪些?

一.摘要 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 1.消息的顺序问题 2.消息的重复问题 二.关键特性以及其实现原理 2.1.顺序消息 要实现严格的顺序消息,简单且可行的办法就是: 保证生产者 - MQServer - 消费者是一对一对一的关系 这样的设计虽然简单易行,但也会存在一些很严重的问题,比如: 1.并行度就会成为消息系统的瓶颈(吞吐量不够) 2.更多的异常处理,比如:只要消费端出现问题,就会

发送方确认模式 将信道设置成 confirm 模式(发送方确认模式),则所有在信道上发布的消息都会被指派一个唯一的 ID.一旦消息被投递到目的队列后,或者消息被写入磁盘后(可持久化的消息),信道会发送一个确认给生产者(包含消息唯一 ID). 如果 RabbitMQ 发生内部错误从而导致消息丢失,会发送一条 nack(notacknowledged,未确认)消息. 发送方确认模式是异步的,生产者应用程序在等待确认的同时,可以继续发送消息.当确认消息到达生产者应用程序,生产者应用程序的回调方法就会被

发送方确认模式 将信道设置成 confirm 模式(发送方确认模式),则所有在信道上发布的消息都 会被指派一个唯一的 ID. 一旦消息被投递到目的队列后,或者消息被写入磁盘后(可持久化的消息),信 道会发送一个确认给生产者(包含消息唯一 ID). 如果 RabbitMQ 发生内部错误从而导致消息丢失,会发送一条 nack(not acknowledged,未确认)消息. 发送方确认模式是异步的,生产者应用程序在等待确认的同时,可以继续发送消 息.当确认消息到达生产者应用程序,生产者应用程序的回调

本文地址:http://www.cnblogs.com/wuyudong/p/5900800.html,转载请注明源地址. 1.解析json数据 解析json的代码很简单 JSONObject jsonObject = new JSONObject(json); //debug调试,解决问题 String versionName = jsonObject.getString("versionName"); mVersionDes = jsonObject.getString("

一.前言 通过上一篇的学习我们知道了消息分为三个部分,即消息头,属性及消息体,并对消息头的十个属性进行了详细的介绍,本文再对消息属性及消息体进行详细的介绍. 二.属性介绍 消息属性的主要作用是可以对头信息进行一个额外的补充,毕竟消息头信息一是有限,二是很多不能由应用程序设定.通常,消息属性可以用在消息选择器的表达式里,结合起来实现对消息的过滤. 消息属性的值只能是基本的类型,或者这些基本类型对应的包装类型.也就是说,不能将一个自定义的对象作为属性值.通常情况下,如果能够放在body里的内容,就不