消息队列介绍及原理

消息队列MQ技术的介绍和原理

(2010-03-14 00:00:00)

转载▼

标签：

杂谈

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

消息中间件概述

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。

设计分布式应用的方法主要有：远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一；对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合；消息队列(MessageQueue)--构造分布式应用的松耦合方法。

(a)分布计算环境/远程过程调用(DCE/RPC)

RPC是DCE的成分，是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另一程序的传统程序设计方法，此引用是过程调用的形式，一旦被调用，程序的控制则转向被调用程序。

在RPC实现时，被调用过程可在本地或远地的另一系统中驻留并在执行。当被调用程序完成处理输入数据，结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则立即返回到调用程序。因此RPC模仿子程序的调用/返回结构，它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。

(b)对象事务监控(OTM)

基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合，在CORBA规范中定义了：使用面向对象技术和方法的体系结构；公共的Client/Server程序设计接口；多平台间传输和翻译数据的指导方针；开发分布式应用接口的语言(IDL)等，并为构造分布的

Client/Server应用提供了广泛及一致的模式。

(c)消息队列(Message Queue)

消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API 调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。

中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操作系统及网络软件之间，它为应用提供了公用的通信手段，并且独立于网络和操作系统。中间件为开发者提供了公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能。

如果没有消息中间件完成信息交换，应用开发者为了传输数据，必须要学会如何用网络和操作系统软件的功能，编写相应的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。例如，为了实现网络上不同主机系统间的通信，将要求具备在网络上如何交换信息的知识（比如用TCP/IP的socket程序设计）；为了实现同一主机内不同进程之间的通讯，将要求具备操作系统的消息队列或命名管道(Pipes)等知识。

目前中间件的种类很多，如交易管理中间件(如IBM的CICS)、面向Java应用的Web应用服务器中间件(如IBM的WebSphere Application Server)等，而消息传输中间件(MOM)是其中的一种。它简化了应用之间数据的传输，屏蔽底层异构操作系统和网络平台，提供一致的通讯标准和应用开发，确保分布式计算网络环境下可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供特有的异步传输机制，能够基于消息传输和异步事务处理实现应用整合与数据交换。

IBM 消息中间件MQ以其独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性，以及强大的事务处理能力和消息通讯能力，成为业界市场占有率最高的消息中间件产品。

MQ具有强大的跨平台性，它支持的平台数多达35种。它支持各种主流Unix操作系统平台,如：HP-UX、AIX、SUN Solaris、Digital UNIX、Open VMX、SUNOS、NCR UNIX；支持各种主机平台，如：OS/390、MVS/ESA、VSE/ESA；同样支持Windows NT服务器。在PC 平台上支持Windows9X/Windows NT/Windows 2000和UNIX (UnixWare、Solaris)以及主要的Linux版本(Redhat、TurboLinux等)。此外，MQ还支持其他各种操作系统平台，如：OS/2、AS/400、Sequent DYNIX、SCO OpenServer、SCO UnixWare、Tandem等。

MQ的基本概念：

1)队列管理器

队列管理器是MQ系统中最上层的一个概念，由它为我们提供基于队列的消息服务。

2)消息

在MQ中，我们把应用程序交由MQ传输的数据定义为消息，我们可以定义消息的内容并对消息进行广义的理解，比如：用户的各种类型的数据文件，某个应用向其它应用发出的处理请求等都可以作为消息。消息有两部分组成：

消息描述符(Message Discription或Message Header)，描述消息的特征，如：消息的优先级、生命周期、消息Id等；

消息体(Message Body)，即用户数据部分。在MQ中，消息分为两种类型，非永久性

(non-persistent)消息和永久性(persistent)消息，非永久性消息是存储在内存中的，它是为了提高性能而设计的，当系统掉电或MQ队列管理器重新启动时，将不可恢复。当用户对消息的可靠性要求不高，而侧重系统的性能表现时，可以采用该种类型的消息，如：当发布股票信息时，由于股票信息是不断更新的，我们可能每若干秒就会发布一次，新的消息会不断覆盖旧的消息。永久性消息是存储在硬盘上，并且纪录数据日志的，它具有高可靠性，在网络和系统发生故障等情况下都能确保消息不丢、不重。

此外，在MQ中，还有逻辑消息和物理消息的概念。利用逻辑消息和物理消息，我们可以将大消息进行分段处理，也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。

3)队列

队列是消息的安全存放地，队列存储消息直到它被应用程序处理。

消息队列以下述方式工作：

a) 程序A形成对消息队列系统的调用，此调用告知消息队列系统，消息准备好了投向程序B；

b) 消息队列系统发送此消息到程序B驻留处的系统，并将它放到程序B的队列中；

c) 适当时间后，程序B从它的队列中读此消息，并处理此信息。

由于采用了先进的程序设计思想以及内部工作机制，MQ能够在各种网络条件下保证消息的可靠传递，可以克服网络线路质量差或不稳定的现状，在传输过程中，如果通信线路出现故障或远端的主机发生故障，本地的应用程序都不会受到影响，可以继续发送数据，而无需等待网络故障恢复或远端主机正常后再重新运行。

在MQ中，队列分为很多种类型，其中包括：本地队列、远程队列、模板队列、动态队列、别名队列等。

本地队列又分为普通本地队列和传输队列，普通本地队列是应用程序通过API对其进行读写操作的队列；传输队列可以理解为存储-转发队列，比如：我们将某个消息交给MQ系统发送到远程主机，而此时网络发生故障，MQ将把消息放在传输队列中暂存，当网络恢复时，再发往远端目的地。

远程队列是目的队列在本地的定义，它类似一个地址指针，指向远程主机上的某个目的队列，它仅仅是个定义，不真正占用磁盘存储空间。

模板队列和动态队列是MQ的一个特色，它的一个典型用途是用作系统的可扩展性考虑。我们可以创建一个模板队列，当今后需要新增队列时，每打开一个模板队列，MQ便会自动生成一个动态队列，我们还可以指定该动态队列为临时队列或者是永久队列，若为临时队列我们可以在关闭它的同时将它删除，相反，若为永久队列，我们可以将它永久保留，为我所用。

4)通道

通道是MQ系统中队列管理器之间传递消息的管道，它是建立在物理的网络连接之上的一个逻辑概念，也是MQ产品的精华。

在MQ中，主要有三大类通道类型，即消息通道，MQI通道和Cluster通道。消息通道是用于在MQ的服务器和服务器之间传输消息的，需要强调指出的是，该通道是单向的，它又有发送(sender), 接收(receive), 请求者(requestor), 服务者(server)等不同类型，供用户在不同情况下使用。MQI通道是MQ Client和

MQI通道是MQ Client和MQ Server之间通讯和传输消息用的，与消息通道不同，它的传输是双向的。群集(Cluster)通道是位于同一个MQ 群集内部的队列管理器之间通讯使用的。

MQ的工作原理(图见附件)

首先来看本地通讯的情况，应用程序A和应用程序B运行于同一系统A，它们之间可以借助消息队列技术进行彼此的通讯：应用程序A向队列1发送一条信息，而当应用程序B需要时就可以得到该信息。

其次是远程通讯的情况，如果信息传输的目标改为在系统B上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列2发送一条信息，系统A的MQ发现Q2所指向的目的队列实际上位于系统B，它将信息放到本地的一个特殊队列－传输队列(Transmission Queue)。我们建立一条从系统A到系统B的消息通道，消息通道代理将从传输队列中读取消息，并传递这条信息到系统B，然后等待确认。只有MQ接到系统B成功收到信息的确认之后，它才从传输队列中真正将该信息删除。如果通讯线路不通，或系统B 不在运行，信息会留在传输队列中，直到被成功地传送到目的地。这是MQ最基本而最重要的技术--确保信息传输，并且是一次且仅一次(once-and-only-once)的传递。

MQ提供了用于应用集成的松耦合的连接方法，因为共享信息的应用不需要知道彼此物理位置（网络地址）；不需要知道彼此间怎样建立通信；不需要同时处于运行状态；不需要在同样的操作系统或网络环境下运行。

MQ的基本配置举例

在上图中，要实现网络上两台主机上的通讯，若采用点对点的通讯方式，我们至少要建立如下MQ的对象：

在发送方A:

1）建立队列管理器QMA: crtmqm -q QMA

2）定义本地传输队列: define qlocal (QMB) usage (xmitq) defpsist(yes)

3）创建远程队列: define qremote (QR.TOB) rname (LQB) rqmname (QMB) xmitq (QMB)

4）定义发送通道: define channel (A.TO.B) chltype (sdr) conname ('IP of B') xmitq (QMB) + trptype (tcp)

在接收方B：

1）建立队列管理器QMB: crtmqm -q QMB

2）定义本地队列QLB: define qlocal (LQB)

3）创建接收通道: define channel (A.TO.B) chltype (rcvr) trptype (tcp)

经过上述配置，我们就可以实现从主机A到B的单向通讯，若要实现二者之间的双向通讯，可参考此例创建所需要的MQ对象。

MQ的通讯模式

1) 点对点通讯：点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。

2) 多点广播：MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ 将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。

3) 发布/订阅(Publish/Subscribe)模式：发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。在MQ家族产品中，MQ Event Broker是专门用于使用发布/订阅技术进行数据通讯的产品，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。

4) 群集(Cluster)：为了简化点对点通讯模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。

RabbitMQ的应用场景以及基本原理介绍

RabbitMQ的应用场景以及基本原理介绍 1.背景 RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。 2.应用场景 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式 (1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西. (2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

假设三个业务节点分别使用50ms,串行方式使用时间 150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回. (3)消息队列 引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理 由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。2.2 应用解耦 场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.

这种做法有一个缺点: 当库存系统出现故障时,订单就会失败。(这样马云将少赚好多好多钱^ ^)订单系统和库存系统高耦合. 引入消息队列 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。库存系统:订阅下单的消息,获取下单消息,进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了). 流量削峰 流量削峰一般在秒杀活动中应用广泛 场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。 作用: 1.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为

IBM MQ 概述

IBM MQ 介绍 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、操作系统以及通信协议的网络彼此进行通信。例如，IBM WebSphere MQ 支持35 种以上的不同操作系统。 IBM WebSphere MQ 支持两种不同的应用程序编程接口：Java 消息服务（JMS）和消息队列接口（MQI）。在IBM WebSphere MQ 服务器上，JMS 绑定方式被映射到MQI。如图 3 所示，应用程序直接与其本地队列管理器通过使用MQI 进行对话，MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口，因为大部分艰苦工作都将透明完成的。 图形 2. IBM WebSphere MQ 编程 图2 显示了IBM WebSphere MQ 编程的原理。第一步是让应用程序与队列管理器连接。它通过MQConnect 调用来进行此连接。下一步使用MQOpen 调用为输出打开一个队列。然后应用程序使用MQPut 调用将其数据放到队列上。要接收数据，应用程序调用MQOpen 调用打开输入队列。应用程序使用MQGet 调用从队列上接收数据。

队列研究的设计、实施及方法学问题

【摘要】队列研究在循证医学的证据等级中为ⅱ级证据，仅次于随机对照试验，是临床医疗防治措施评价的重要证据来源之一。近年来开始在传统医学疗法评价中得到应用。本文较为系统地介绍了队列研究的基本概念、原理、设计类型、实施步骤以及在中医药领域运用的关键方法学问题，旨在为中医药的临床研究拓宽思路，为新方法的引用提供借鉴。 【关键词】队列研究; 循证医学; 评价研究 1 队列研究的历史和概念 队列（cohort）是指具有共同经历、暴露或特征的一群人或研究组。该词起源于拉丁文cohors，字面意思是指封闭的场所中的人群，古罗马时期列队的士兵单位即构成一个队列。队列研究（cohort study）最早用于研究与疾病发生相关的病因或危险因素，将一群研究对象按是否暴露于某因素分成暴露组和非暴露组，随访适当长的时间，比较两组之间所研究疾病或结局发生率的差异，以研究这个（些）暴露因素与疾病或结局之间的关系。暴露是一个流行病学概念，是指人群处于某一场景之中接近或接触致病因子，致使其对人体产生有害影响；暴露因素既包括危险因素和致病因素，如吸烟等不良生活习惯，也同时包括保护性因素，如疫苗接种。暴露的概念已经从传统意义上的外界因素，扩大到机体内在的某种特征。队列研究中的暴露通常是指当前的暴露状态、既往暴露、将来可能的暴露或不暴露以及暴露程度不同的暴露。 20世纪80年代，人们开始将队列研究用于研究医疗防治措施，此时，暴露指具有预防保健或治疗作用的医疗措施，暴露因素成为有益的保护因素，研究的目的也从疾病发生转为治疗结局的评价。治疗性队列研究是将特定患病人群根据其是否接受某种（类）治疗措施或接受不同类别的治疗措施分为不同的亚组，然后追踪观察一定时间，比较治疗组和对照组结局事件的发生率（如病死率）或治愈率的差异。队列研究也可用于预防性措施或方案的评价。因此，近年来队列研究在国家级中医药防治效果评价研究中开始受到重视并得到采用。 2 队列研究的方法学原理 队列研究属于流行病学观察性研究，其基本原理是基于事物的因果关联，即假设疾病的发生必定有其原因，而这种原因可以是病因，也可以是增加疾病发生概率的危险因素。队列研究是由因到果的研究，大多是前瞻性的。它与回顾性研究的最大区别是“因”在前，而“果”在后。 在开展前瞻性队列研究前，所研究的暴露因素已经存在，研究者知道每个研究对象的暴露情况，必须随访一段足够的时间（通常为数年），观察疾病发生或结局的出现。而在开始回顾性队列研究前，暴露因素和结果都已经发生，研究目的是比较结果在暴露和非暴露两组人群的发生概率，如对癌症病例的调查就可以采用回顾性队列研究。 由于治疗与结局之间也属于因果关联的一种类型，因此，人们也把队列研究用于治疗措施的效果评价。此时，暴露是指接受的治疗措施，而结局是观察评价的效果。 2.1 队列研究的应用范畴 2.1.1 研究综合防治措施或方案的作用 由于传统医学防治疾病的模式与西方医学的对抗模式有很大不同，主要体现在整体调节和辨证论治，传统医学往往采用包括药物与非药物在内的多种治疗措施，因此，它起效的作用决不是单一措施的作用，获得的效果也是综合的总体疗效。采用经典的随机对照试验评价则面临方法学和伦理学的挑战，比如，肿瘤的中医药辅助治疗。 由于受到医学伦理学的限制，在不能使用随机对照试验的情况下，可以用队列研究来评估干预措施的疗效。例如在严重急性呼吸综合征（severe acute respiratory syndrome, sars）（中国称为非典型肺炎）暴发期间，不可能使用随机对照试验评估中药对此急性传染病的预防效果，因此有研究运用前瞻性队列研究在香港的11所医院对中药预防sars的效果进行了观察。预防组1 063名医护工作者服用中药2周，对照组36 111名医护工作者未服用中

MQ介绍与选型

MQ介绍与选型 MQ使用场景 ?异步通信 有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 ?解耦 降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 ?冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 ?扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。 ?过载保护

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 ?可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 ?顺序保证 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。 ?缓冲 在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。 以调节系统响应时间。 ?数据流处理 分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

zeromq的工作原理及使用

zeromq的工作原理及使用

一、ZeroMQ使用 1.1ZeroMQ概述 ZeroMQ是一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。ZeroMQ是网络通信中新的一层，介于应用层和传输层之间（按照TCP/IP划分），其是一个可伸缩层，可并行运行，分散在分布式系统间。 ZeroMQ看起来想一个可嵌入的网络库，但其作用就像是一个并发框架。它为你提供了各种传输工具，如进程内，进程间，TCP和组播中进行原子消息传递的套接字。你可以使用各种模式实现N对N的套接字连接，这些模式包括发布订阅，请求应答，扇出模式，管道模式。它的速度足够快，因此可以充当集群产品的结构，他的异步IO模型提供了可扩展的多核应用程序，用异步消息来处理任务。它虽然是以C为源码进行开发，但是可以绑定多种语言。 1.2请求/应答模式 说到“请求-应答”模式，不得不说的就是它的消息流动模型以及数据包装模型。 消息流动模型指的是该模式下，必须严格遵守“一问一答”的方式。发出消息后，若没有收到回复，再发出第二条消息时就会抛出异常。同样的，对于Rep也是，在没有接收到消息前，不允许发出消息。基于此构成“一问一答”的响应模式。 1.2.1服务端 import time import zmq

context=zmq.Context() socket=context.socket(zmq.REP) socket.bind("tcp://*:5555") while True: #Wait for next request from client message=socket.recv() print("Received request:%s"%message) #Do some'work' time.sleep(1) #Send reply back to client socket.send(b"World") 1.2.2客户端 import zmq context=zmq.Context() #Socket to talk to server print("Connecting to hello world server…") socket=context.socket(zmq.REQ) socket.connect("tcp://localhost:5555") #Do10requests,waiting each time for a response for request in range(10): print("Sending request%s…"%request) socket.send(b"Hello") #Get the reply. message=socket.recv() print("Received reply%s[%s]"%(request,message))

嵌入式操作系统核原理开发(消息队列)

嵌入式操作系统内核原理和开发（消息队列） 消息队列是线程交互的一种方法，任务可以通过消息队列来实现数据的沟通和交换。在嵌入 式系统上，这可以说这是用的最多的一种方法。通过消息队列，无论是发送者，还是接受者 都可以循环地处理各种消息。而我们知道，存储消息最好的方式就是循环队列，如果消息已 满，那么发送者可以把自己pend到等待队列上；而如果此时没有消息，那么接受者也可以 把自己pend到等待队列上。当然实现消息队列的方法很多，甚至用户可以自己利用互斥量 和信号量来实现，而嵌入式系统常常会默认提供这样的功能函数，我想主要的目的还是为了 方便用户，让他们可以更多地从业务的角度来看问题，而不是把重点关注在这些底层的细节 上面。 首先，我们还是看看rawos上面关于消息队列的数据结构是怎么定义的， 1typedef struct RAW_MSG_Q { 2 3 RAW_VOID **queue_start; /* Pointer to start of queue data */ 4 RAW_VOID **queue_end; /* Pointer to end of queue data */ 5 RAW_VOID **write; /* Pointer to where next message will be inserted in the Q */ 6 RAW_VOID **read; /* Pointer to where next message will be extracted from the Q */ 7 RAW_U32 size; /* Size of queue (maximum number of entries) */ 8 RAW_U32 current_numbers; /* Current number of entries in the queue */ 9 RAW_U16 blocked_send_task_numbers; /*number of blocked send task numbers */ 10 RAW_U16 blocked_receive_task_numbers; /*number of blocked send task numbers */ 11 12 } RAW_MSG_Q; 13 14typedef struct RAW_QUEUE 15 { 16 RAW_COMMON_BLOCK_OBJECT common_block_obj; 17 RAW_MSG_Q msg_q; 18 19 } RAW_QUEUE; 上面的代码中有两段数据结构，第一段主要表示循环队列的内容，其中包括了队列首地

posix消息队列使用全面介绍

POSIX消息队列是linux进程间通信的重要方式，下面按照创建，使用，关闭的顺序讲述了POSIX消息队列的使用方法： 创建POSIX消息队列： mq_open #include mqd_t mq_open(const char *name,int oflag,int mode,mq_addr *attr); 参数说明： Name：消息队列的名字字符串，必须以’/’开头，否则会出错。 Oflag: 表示打开的方式， 1．首先必须说明读写方式，可以使以下的值之一： O_RDONLY：建立的队列是只读的 O_WRONLY：建立的队列是只写的 O_RDWR：建立的队列是可读可写 2．必须有O_CREATE,说明是创建消息队列。 3．还有可选的选项： O_NONBLOCK：说明在创建的队列上发送和接收消息时，如果没有资源，不会 等待，之间返回，如果不设置这个选项，缺省是会等待。 O_EXCL：在创建队列时，检测要创建的队列的名字是否已经存在了，如果已存 在，函数会返回出错 可以以或的方式形成Oflag，例如：O_RDWR|O_CREAT|O_EXCL Mode：是一个可选参数，在oflag中含有O_CREA T标志且消息队列不存在时，才需要提供该参数。表示默认的访问权限，这个权限和文件访问的权限是相同的，取值也 相同。 Mode可以由多个值组合而成，如：S_IRUSR|S_IWUSR，队列的所有者有读和 写的权限。 Attr：指向结构struct mq_attr的指针。我们可以在创建队列时通过这个结构设置队列的最大消息数和每个消息的最大长度。 struct mq_attr { long mq_flags; // 0或者O_NONBLOCK，说明是否等待

队列研究设计要点.doc

队列研究设计要点 研究对象：暴露组与对照组人群,选择时要考虑除了暴露因素以外,其他因素要尽量均衡。 研究因素：除了暴露因素以外,还会有混杂因素,注意必须设计进去加以分析。所研究的因素,可以是分类资料,也可以是计量资料。 效应指标：结局的发生,结局可以是一因多果的。有一类特殊的效应指标,包括结局和到达结局所经历的时间两维信息,要采用生存分析和COX回归的方法。 科学性原则：对照、均衡（依靠三大标准） 病例对照研究设计要点 研究对象：病例组一般采用确诊的新发病例。对照对象必须来自于产生病例的总体。 研究因素：怀疑与所研究疾病有可能发生联系的因素。多数情况下是多因素,可以是分类资料,也可以是计量资料。 效应指标：分组依据,病例的概念是广义的,病例要有明确可靠诊断。明确纳入、排除标准。 科学性原则：对照、均衡（依靠三大标准） 诊断性研究设计要点 确定金标准：确定有可靠的金标准 选择研究对象：包括病例、需要鉴别的人群 盲法、独立和同步比较诊断试验和“金标准”结果 ROC分析：评价诊断价值,寻找诊断临界点。 随机对照试验设计要点 研究对象：随机分组,诊断标准、纳入标准、排除标准是保证研究对象同质性的重要手段。 研究因素：不同的干预方法,应详细介绍干预方法和对照方法的具体细节。 效应指标：效应指标可以有多种选择,需根据专业目的灵活恰当采用。近期、远期；计量资料、计数资料。 科学性原则：如何实现这些原则（随机、对照、盲法、均衡评价）,具体如何操作,应要重点进行设计。 预后研究设计关键点 研究对象：分组,诊断标准、纳入标准、排除标准是保证研究对象同质性的重要手段。 研究因素：不同的影响预后的因素（包括自然形成的干预方法）。 效应指标：效应指标可以有多种选择,需根据专业目的灵活恰当采用。重点关注失访、与时间相结合的结局指标。 科学性原则：对照、均衡（依靠三大标准）。 定性研究设计要点 常用德尔菲专家法：有数据、有过程。在医学研究中,一般不单独使用,常作为一个研究项目的组成部分出现。 关注研究过程,重点理解好定性研究的报告规范 卫生经济评价的设计要点 在临床研究中,不要套用管理领域的卫生经济学评价方法,需要与临床作用结合起来评价。 临床研究领域常用成本效果和成本效用分析。 成本的计算有很多停留于理论阶段,实际处理有难度时,可以采用组间均衡的原则进行处理。 研究对象的可比性是直接关系到临床研究中卫生经济学评价结果好坏的关键。 数据挖掘研究设计要点 数据采集：信息真实性,可靠性,代表性 数据预处理：规范整齐的数据是最大的问题,事先确定标准,或者事后按标准进行数据清理。 数据挖掘：不只是描述,需要借助数据挖掘工具。也不仅是统计,统计是验证假设,数据挖掘是发现规律。 分析工具：用好工具是开展此类研究的关键。 6、简述队列研究的特点。 答：定群调查又称队列研究或前瞻性研究,常在进行病例对照研究的基础上,推测某病与某个危险因素有关联。为了进一步验证这种关联关系,选择两组人群进行追踪调查,其中一组人群处在这个危险因素影响中,另一组人群除了不处在这个危险因素影响中,其他方面尽可能与前一组人群相同。通过研究两组人群发病率的差异来判定危险因素与发病有无关联关系以及关联程度的大小。 9、简述设立对照应注意的问题？ 答：1.组间应具有可比性 2.以人为试验对象的研究,组间对比时应考虑受试者心理因素的影响。3.对照组与试验组的例数应尽量相当。4.自身前后对照应注意评价指标是否随时间的先后而变化。.受试对象的病理强度应适当 14、简述混杂因素的控制方法 答：（1）配对：是一种常用的避免混杂因素的重要方法。常用的变量有性别、年龄、病情等。配对时应注意：①配对项目不应过多,因素越多越难找到合适的对照组。 ②不能将研究因素进行配对。 （2）分层分析：也是一种常用的避免混杂因素的重要方法。分层是指分层抽样选择研究对象,或将研究结果分层分析研究资料。 （3）随机化：严格的随机化方法能够消除各种影响因素在组间的分布差异,使研究结果具有可比性。在临床试验中最为常用 （4）限制：即对试验组与对照组人员的条件加以某种控制。在科学研究进行组间比较时,除了研究因素在组间不同外,其它因素均应完全一样。通过对某些因素的限定,以增强样本的代表性。 15、简述提高试验效率的方法 答：（一）选择患病率高的人群作为受试对象：患病率高,阳性预测值高,诊断出的病人数多,试验效率提高（二）联合试验： 1、平行（并联）试验 同时进行几种诊断目的相同的诊断试验,只要其中一个试验结果为阳性即判断为阳性。平行试验提高灵敏度及阴性预测值,减少漏诊率,但却增加了误诊率,降低特异度。 当漏掉一个病人后果严重或再进行筛检费人力物力时,要尽量减少漏诊率,可采用此方法。 2、系列（串联）试验 进行一系列诊断目的相同诊断试验,只有所有试验结果都为阳性时判断为阳性。系列试验可提高特异度和阳性预测值,减少误诊率,但增加漏诊率,降低灵敏度。当误

RabbitMQ的应用场景以及基本原理介绍

RabbitMQ 的应用场景以及基本原理介绍 1. 背景 RabbitMQ 是一个由erlang 开发的AMQP(Advanved Message Queue) 的开源实现。 2. 应用场景 2.1 异步处理 场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1. 串行的方式;2.并行的方式 (1) 串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信, 以上三个任务全部完成后才返回给客户端。这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西. (2) 并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信, 以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

假设三个业务节点分别使用50ms, 串行方式使用时间150ms, 并行使用时间100ms 。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回. (3) 消息队列 引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理 由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3 倍,是并行的2 倍。2.2 应用解耦 场景：双11 是购物狂节,用户下单后,订单系统需要通知库存 系统,传统的做法就是订单系统调用库存系统的接口

这种做法有一个缺点: 当库存系统出现故障时,订单就会失败。（这样马云将少赚好多好多钱八八）订单系统和库存系统高耦合 引入消息队列 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。库存系统:订阅下单的消息,获取下单消息,进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递 不会导致消息丢失（马云这下高兴了）. 流量削峰 流量削峰一般在秒杀活动中应用广泛 场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。 作用: 1. 可以控制活动人数，超过此一定阀值的订单直接丢弃（我

消息队列

学号： 嵌入式系统及应用 实验报告 消息队列 学生姓名 班级 成绩

简介 消息队列就象一个类似于缓冲区的对象，通过消息队列任务和ISR发送和接收消息，实现数据的通信和同步。消息队列具有一定的容量，可以容纳多条消息，因此可以看成是多个邮箱的组合。 1、实验目的 a）理解消息队列的基本原理，了解任务的各个消息队列基本状态及其变迁过程； b) 掌握μC/OS-II中消息队列管理的基本方法（创建、启动、挂起、解挂任务）； c)熟练使用μC/OS-II消息队列管理的基本系统调用。 2、实验原理及程序结构 2.1 实验设计 为了说明如何使用消息队列来实现多任务接收数据，我们设计一个系统，按键一按下，LED按照指定节奏闪耀，蜂鸣器按照指定节奏鸣响。假设TaskLED为高优先级的任务，三个任务的处理流程如下。

TaskKEY任务主要代码如下。 LED任务的代码如下。

Beep任务主要代码如下。 源程序说明

1、需在以下文件中配置如下内容 OS_CFG.H OS_MAX_QS N 你需要的值 根据需要自己配置 #define OS_Q_EN 1 /* Enable (1) or Disable (0) code generation for QUEUES */ #define OS_Q_ACCEPT_EN 1 /* Include code for OSQAccept() */ #define OS_Q_DEL_EN 1 /* Include code for OSQDel() */ #define OS_Q_FLUSH_EN 1 /* Include code for OSQFlush() */ #define OS_Q_POST_EN 1 /* Include code for OSQPost() */ #define OS_Q_POST_FRONT_EN 1 /* Include code for OSQPostFront() */ #define OS_Q_POST_OPT_EN 1 /* Include code for OSQPostOpt() */ #define OS_Q_QUERY_EN 1 /* Include code for OSQQuery() */ 2、建立一个指向消息数组的指针和数组的大小，该指针数组必须申明为void类型，如下： void *MyArrayOfMsg[SIZE]; 3、声明一个OS_EVENT类型的指针指向生成的队列，如下： OS_EVENT *QSem； 4、调用OSQcreate()函数创建消息队列，如下： QSem = OSQcreate(&MyArrayOfMsg[0],SIZE); 5、等待消息队列中的消息，OSQPend()。void *OSQPend (OS_EVENT *pevent, INT16U timeout, INT8U *err): 必须保证消息队列已经被建立。 timeout定义的是等待超时时间，如果为0则表示无期限的等待 err表示的是在等待消息队列出错时的返回类型，有以下几种： OS_ERR_PEVENT_NULL //消息队列不存在 OS_ERR_EVENT_TYPE OS_TIMEOUT //消息队列等待超时 OS_NO_ERR //消息队列接收到消息 获得消息队列示例 type *GETQ; INT8U err; GETQ = (type *)OSQPend(QSem, time, &err); if(err == OS_NO_ERR){ 无错处理 } else{ 出错处理 } 6.1 向消息队列发送一则消息(FIFO),OSQPost(); INT8U OSQPost (OS_EVENT *pevent, void *msg): 函数返回值有： OS_ERR_PEVENT_NULL OS_ERR_POST_NULL_PTR OS_ERR_EVENT_TYPE OS_Q_FULL OS_NO_ERR 参数：pevent,*msg

4.1消息队列服务

通过认证服务的学习，我们可以以不同的身份访问企业云平台，可以通过研发部的账户登录研发部，可以通过业务部访问业务部的资源，也可以通过IT 工程部的身份登录查看整个系统的运行状况；下面我们继续学习消息服务（RabbitMQ ）、镜像服务（Glance ）和计算控制服务（Nova ），了解这3个组件是如何为平台的正常运行提供支撑的。 了解RabbitMQ 、Glance 和Nova 的基本概念。 理解3种服务的服务流程和工作机制。 掌握3种服务的基本操作及常见运维。 消息队列服务 在日常的工作生活中，消息传递是一个必不可少的需求。在大型软件的内部信息交换和外部信息传递中，消息传递都是不可或缺的。在系统间通信窗体的最基本方法是socket ，但是这是一个最底层的协议，所以在使用时需要程序来调用。 在进行后序的学习过程之前，小李首先要了解消息服务的基本状况和使用的情景，以及OpenStack 的RPC （远程呼叫机制）的运行机制。 1．消息队列 AMQP 是一种标准化的消息中间件协议，全称为高级消息队列协议（advanced message queuing protocol ）。可以让不同语言、不同系统的应用互相通信，并提供一个简单统一的模型和编程接口。这样，就可以采用各种语言和平台来实现自身的应用，当需要和其他系统通信时，只要承认AMQP 协议即可。 2．Rabbitmq 消息服务 RabbitMQ 是一个基于AMQP 协议的高级消息中间件，它主要的技术特点是可用性， 学习目标 项目 基础控制服务 四

OpenStack 云计算基础架构平台技术与应用 52 提示 available ）高可用性集群。 1．了解消息队列AMQP 消息队列AMQP 服务架构，如图4-1所示。 AMQP 中有3个重要的角色，如图4-2所 示。 Publisher ：消息的发出者。 Exchange ：消息的传递者。 Consumer ：消息的接收者。 用户可以模拟写信作为其工作的方式来说 明。为了传递给收件人，首先需要用信封把信 的内容装起来，然后在信封上写好收件人的信 息，再把信放到邮筒里；后面邮局会拿到信然 后根据信封上的收件人信息来看最终把信给 谁。写信的人就是那个Publisher ，邮局就是 Exchange ，收件人就是Consumer 。 不同的Consumer 会创建不同的Queue （消息队列），然后将对应的Exchange 绑定到Queue 上。在消息的传递过程中，Publisher 不会直接的把Message 放到Queue 中，也不管Message 如何分发。Publisher 只管准备好消息，然后交给 Exchange ，而Exchange 做的事情也很简单，一手从Publisher 拿到消息，然后就把消息放入Queue 中。 对于Exchange ，是放到某一个Queue 中，还是放到多个Queue ？实际上，在Publisher 发出消息的时候会附加一个条件，Exchange 会根据这个条件来决定发送的方法，这个条件就是 routingkey 。 图4-2 AMQP 消息传递示意图 2．了解Rabbitmq 消息服务 Rabbitmq 架构图，如图4-3所示。 通过上面这张应用相结合的结构图既能够清晰的看清楚整体的send Message 到 图4-1 AMQP 架构图

windows消息和消息队列实例详解

本文详细讲述了windows消息和消息队列的原理与应用方法。分享给大家供大家参考。具体分析如下： 与基于MS - DOS的应用程序不同，Windows的应用程序是事件(消息)驱动的。它们不会显式地调用函数（如C运行时库调用）来获取输入，而是等待windows向它们传递输入。wi ndows系统把应用程序的输入事件传递给各个窗口，每个窗口有一个函数，称为窗口消息处理函数。窗口消息处理函数处理各种用户输入，处理完成后再将控制权交还给系统。窗口消息处理函数一般是在注册一个窗口的时候指定的。你可以从典型的SDK程序中窗口消息处理函数是怎么声明和实现的。 对于Windows XP系统：如果顶层窗口停止响应消息超过几秒钟，系统会认为窗口无回应。在这种情况下，系统将隐藏这个窗口，然后生成一个影子(ghost)窗口覆盖在它上面。这个影子窗口具有着相同的Z轴顺序，位置，大小，显示属性。影子窗口允许用户将其移动，调整大小，甚至关闭(关闭的是停止响应的window)。此时只有这几个动作是被允许的，在调试模式下，系统不会生成影子窗口。 本节讨论以下主题： Windows消息 1. 消息类型 2. 消息传递 3. 消息处理 4. 消息过滤 5. post message和send message

6. 消息死锁 7. 广播消息 8. 查询消息 现分述如下： 1. Windows消息 windows通过消息的形式向窗口传递用户输入。消息可以由系统和应用程序生成。该系统会为每个输入事件产生相应的消息， 例如，用户点击鼠标，移动鼠标或滚动条，或是应用程序改变了系统的某些属性，比如说系统更改了字体资源，改变了某个窗口的 大小。不仅如此，应用程序可以生成消息，通告发送消息指定它的窗体去执行某些任务或者是与其他的应用程序交互。 windows系统将消息发送到一个窗口消息处理函数时传递四个参数：窗口句柄，消息标识符，两个DWORD值(消息参数)。 窗口句柄标识了该消息的目的窗口。windows使用它来确定是哪个窗口的的窗口消息处理函数收到该消息。 一个消息标识符是一个有名字的常量，用来表明消息的意义。当一个窗口处理函数收到一条消息，它根据判断消息标识符来决定如何处理该消息，例如，消息标识符WM_PAINT消息告诉窗口程序窗口的客户区已发生变化，必须重绘。消息参数(DWORD值)指定传递的数据或是数据的地址。消息参数可以是一个整型值，一个指针值。也可以为NULL。

MQ原理

WebSphere MQ的工作原理介绍 Websphere MQ是IBM的商业通讯中间件(Commercial Messaging Middlew are)。Websphere MQ提供一个具有工业标准、安全、可靠的消息传输系统。它的功能是控制和管理一个集成的商业应用，使得组成这个商业应用的多个分支程序(模块)之间通过传递消息完成整个工作流程。Websphere MQ基本由一个消息传输系统和一个应用程序接口组成，其资源是消息和队列(Messaging and Queuing)。 消息：消息就是一个信息单元，这个信息单元可以是一个请求（Request message），也可以是一个应答(Reply message)，或者是一个报告(Report message)或一份报文(Datagram messge)。一个消息包含两个因素——消息描述(用于定义诸如消息传输目标等)和数据消息(如应用程序数据或数据库查询等)。程序之间的通信通过传递消息而非直接调用程序。 队列:一个安全的存储消息的地方，消息的存储一般是顺序的，队列是消息分阶段地传送和接收。因为消息存放在队列中，所以应用程序可以相互独立的运行，以不同的速度，在不同的时间，在不同的地点。 消息传输系统：用于确保队列之间的消息提供，包括网络中不同系统上的远程队列之间的消息提供。并保证网络故障或关闭后的恢复。 应用程序接口：应用程序和消息系统之间通过Websphere MQ AP I实现的接口Websphere MQ AP I在所有Websphere MQ平台上是一致的。AP I只有14个调用，2个关键动词：发送(P UT)和接收(GE T)。 WebSphere MQ是一个消息队品，专门负责在各种平台间传送数据，能保证 数据在不稳定的数据线路上传送时不会丢失或重复，本文主要向大家介绍 WebSphere MQ的工作原理. 适用操作系统：跨平台 WebSphere MQ 是IBM用于通讯的中间件产品，它为分布式环境下进行程序 到程序之间通信提供了灵活、快速并且易于使用的解决方法。WebSphere MQ 为应用程序提供一种跨越网络通讯的特殊机制，参与通讯的应用程序之间 不需要建立私有的、专用的逻辑连接，它们只需要把数据组装成消息，放 入消息队列中，接收方从消息队列中取出消息，达到通信的目的。下面简 要介绍WebSphere MQ的工作原理： WebSphere MQ支持应用程序交换数据的基本机制是消息与队列。如下图中的程序A与程序B要交换数据，A先把数据组织成一个称为消息的数据包，放入队列中，队列是由队列管理器管理的一个数据文件，由队列管理保证放在队列中的消息的完整性和可恢复性，即消息放入队列后，即

消息队列架构设计

如果让你写一个消息队列，该如何进行架构设计？说一下你的思路。 其实聊到这个问题，一般面试官要考察两块： ?你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理。 ?看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来。 说实话，问类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问 题，比如，如果让你来设计一个Spring 框架你会怎么做？如果让你来设计一个Dubbo 框架你会怎么做？如果让你来设计一个MyBatis 框架你会怎么做？ 其实回答这类问题，说白了，不求你看过那技术的源码，起码你要大概知道那个技术的基本原理、核心组成部分、基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好。 比如说这个消息队列系统，我们从以下几个角度来考虑一下： ?首先这个mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka 的设计理念，broker -> topic -> partition，每个partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic 增加partition， 然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量 了？

?其次你得考虑一下这个mq 的数据要不要落地磁盘吧？那肯定要了，落 磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序 写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka 的思路。 ?其次你考虑一下你的mq 的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的kafka 的高可用保障机制。多副本-> leader & follower -> broker 挂了重新选举leader 即可对外服务。 ?能不能支持数据0 丢失啊？可以的，参考我们之前说的那个kafka 数据零丢失方案。 mq 肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有 没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。

消息队列(Message Queue)简介及其使用

消息队列（Message Queue）简介及其使用 利用MSMQ（Microsoft Message Queue），应用程序开发人员可以通过发送和接收消息方便地与应用程序进行快速可靠的通信。消息处理为您提供了有保障的消息传递和执行许多业务处理的可靠的防故障方法。 MSMQ与XML Web Services和.Net Remoting一样，是一种分布式开发技术。但是在使用XML Web Services或.Net Remoting组件时，Client端需要和Server端实时交换信息，Server需要保持联机。MSMQ则可以在Server离线的情况下工作，将Message临时保存在Client端的消息队列中，以后联机时再发送到Server端处理。 显然，MSMQ不适合于Client需要Server端及时响应的这种情况，MSMQ以异步的方式和Server端交互，不用担心等待Server端的长时间处理过程。 虽然XML Web Services和.Net Remoting都提供了[OneWay]属性来处理异步调用，用来解决Server端长方法调用长时间阻碍Client端。但是不能解决大量Client负载的问题，此时Server接受的请求快于处理请求。 一般情况下，[OneWay]属性不用于专门的消息服务中。 1. 基本术语和概念（Basic terms and concepts） ―消息‖是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。 消息被发送到队列中。―消息队列‖是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

5.进程间的通信原理之消息队列

进程间通信之消息队列 一．原理讲解 消息队列(也叫报文队列)，它是System V3中进程间通信中的一种。 消息队列就是一个消息的链表。我们可以把这个消息看成一个记录[固定 的格式]。这个记录中包含了很多的信息，并且具有一定的格式和优先级。 对消息队列有写权限的进程可以向中按照一定的规则添加新消息；对消息 队列有读权限的进程则可以从消息队列中读走消息。，我们的操作系统提 供了一个struct msg_ids结构体来记录消息队列的全局数据结构。 struct msqid_ds{ struct ipc_perm msg_perm;//被用来传递ipc操作权限信息 struct msg *msg_first; //指向消息队列第一个结点 struct msg *msg_last; //指向详细队列最后一个结点 ……; }; 我们可以将内核中某个特定的消息队列画成一个消息链表。如下图所示，假如一个具有三个消息的队列。长度分别为1byte，2byte和3byte，消息类型(type)为100，200，300.为那么这些消息的排序如下图。

OK,了解了之后，我们来回顾一下，我们以下学习的IPC通信，都是通过一个key值来标识一个ID,那么消息队列的可key值保存在哪里呢？我们来看看我们的 Ipc_perm结构。 二．常用操作 <1>创建消息队列msgget() <2>发送消息队列msgnd()，我们按照一定的类型发送即可。 <3>接收消息队列的信息msgrcv（） <4>删除消息队列msgctl（） 1）创建消息队列

int msgget(key_t key ,int msgflag); 功能：创建消息队列信息。得到其ID 参数： @key IPC_PRIVATE 或者ftok() @msgflg IPC_CREAT | 0666 对应的消息队列不存在，则创建, 存在直接返回ID 或IPC_CREAT | IPC_EXEL | 0666 对应的消息队列段存在则调用失败。 否则，创建新的消息队列段。 返回值：成功返回显示消息队列的ID，失败返回-1 2）发送消息 int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg); 功能:向消息队列中添加消息 参数: msqid 消息队列的ID msgp 消息存放的地址 msgsz 消息正文的大小--- sizeof(msg_t) - sizeof(long)