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 架构图
项目四基础控制服务Receive Message的一个大致的流程。
图4-3 RabbitMQ架构图
首先Rabbitmq有如下几种命令行工具。
①rabbitmqctl：用来管理RabbitMQ中间件的命令行工具.它通过连接中间件节点来执
行所有操作。
②rabbitmq-plugins：rabbitmq-plugins 是管理RabbitMQ broker插件的命令行。
3．OpenStack的消息服务
OpenStack采用AMQP作为它的消息传递技术。AMQP的控制端（Broker），不管是RabbitMQ或者Qpid，它的作用是允许任何两个相同组件以松散耦合的方式进行交流。更准确地说，OpenStack的组件均可以使用远程呼叫机制（RPC）进行彼此沟通。然而，这种范式是建立在“publish/subscribe模式”（订阅/发布模式，订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态）。如图4-4所示。这样做的好处如下。
（1）客户端和服务端之间的解耦（如客户端不需要知道服务引用）。
（2）客户机和服务之间不需要同时使用消息调用，只需要其中一端发送消息调用指令。
（3）随机平衡的远程调用会随机将运行的指令发送到一个节点。
53
OpenStack云计算基础架构平台技术与应用
54
图4-4 OpenStack中的消息服务
下面以计算服务Nova为例，讲解OpenStack组件使用消息服务的原理和机制。Nova
中的每个组件都会连接消息服务器，一个组件可能是一个消息发送者（如API、Scheduler），也可能是一个消息接收者（如compute、volume、network）。
发送消息有2种方式：同步调用rpc.call和异步调用rpc.cast。Nova实现了RPC（包括请求+响应的rpc.call和只有请求的rpc.cast），Nova通过AMQP提供一个代理类，这个类提供了函数调用的消息数据编码和数据解码，每个Nova服务（如计算）在初始化时创建两个队列，一个接受消息路由的关键节点类型产生对应的节点编号”（例如compute.hostname），另一个接受消息路由键返回的节点类型编号生成通用的“节点类型”（例如计算）。前者是专门用来当Nova-API需要重定向命令像terminate（终止）一个实例的在特定的节点，在这种情况下，只有主机的计算节点的虚拟机监控程才能杀死序正在运行的虚拟机实例。API作为消费者当RPC调用请求/响应，否则只是充当发布，如图4-5所示。
4．Nova RPC映射
当一个实例在OpenStack云部署和共享，每个组件在Nova连接到messagebroker，根据其个性，如计算节点或网络节点，可以使用队列作为调用者（如API或调度器）或一个运行组件（如计算或网络）。调用器和组件不实际存在于Nova对象模型，但是在这个例
项目四基础控制服务
子中使用它们作为一个抽象对象。一个调用程序是一个组件，使用rpc发送消息队列系统，接收消息的队列系统，并相应地回复rpc调用操作，如图4-6所示。
图4-5 Nova消息传递
图4-6 OpenStack rpc调用机制
下面介绍几个OpenStack在消息传递过程中常用的对象。
（1）Topic Publisher：该对象在进行rpc.call或rpc.cast调用时创建，每个对象都会连接同一个topic类型的交换器，消息发送完毕后对象被回收。
（2）Direct Publisher：该对象在进行rpc.call调用时创建，用于向消息发送者返回响应。该对象会根据接收到的消息属性连接一个direct类型的交换器。
55
OpenStack云计算基础架构平台技术与应用
56 （3）Direct Consumer：该对象在进行rpc.call调用时创建，用于接收响应消息。每一个
对象都会通过一个队列连接一个direct类型的交换器（队列和交换器以UUID命名）。
（4）Topic Consumer：该对象在内部服务初始化时创建，在服务过程中一直存在。用于从队列中接收消息，调用消息属性中指定的函数。该对象通过一个共享队列或一个私有队列连接一个topic类型的交换器。每一个内部服务都有两个topic consumer，一个用于rpc.cast 调用（此时连接的是binding-key为“topic”的共享队列）。另一个用于rpc.call调用（此时连接的是binding-key为“topic.host”的私有队列）
（5）Topic Exchange：topic类型交换器，每一个消息代理节点只有一个topic类型的交换器。
（6）Direct Exchange：direct类型的交换器，存在于rpc.call调用过程中，对于每一个rpc.call的调用，都会产生该对象的一个实例。
（7）Queue Element：消息队列。可以共享也可以私有。routing-key为“topic”的队列会在相同类型的服务中共享（如多个compute节点共享一个routing-key为“topic”的队列）。
消息队列(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 ） “消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。 消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。“消息队列”是Microsoft 的消息处理技术，它在任何安装了Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。 “消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。 “消息队列”安装期间，管理员确定哪些服务器可以互相通信，并设置特定服务器的特殊角色。构成此“消息队列”网络的计算机称为“站点”，它们之间通过“站点链接”相互连接。每个站点
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.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为
RocketMq消息队列实施计划方案-完整版
消息队列实施方案 1、背景 异步解耦合、给前端系统提供最高效的反应 2、常见消息队列对比 2、1 ActiveMq ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规的JMS Provider实现 优点： Java语言 支持集群模式 缺点： 性能在消息中间件中处于下游 2、2 Rabbitmq Rabbitmq是基于AMQP使用erlang语言实现的消息队列系统 优点： 1、完整的消息队列系统，支持多种消息队列模式，包括竞争消费； 2、支持集群模式，扩展集群容量和性能比较方便，集成了集群的监控和管理； 3、支持消息的持久化； 缺点： 1、需要学习比较复杂的接口和协议，比较耗费时间； 2、性能不是特别理想大概在1wqps左右； 3、使用Erlang语言，语言基础； 2、3 Kafka Kafka 是LinkedIn 开发的一个高性能、分布式的消息发布订阅系统。 优点： 1、分布式集群可以透明的扩展，增加新的服务器进集群。 2、高性能。单机写入TPS约在百万条/秒 3、容错。数据都会复制到几台服务器上。 缺点： 1、复杂性。Kafka需要zookeeper 集群的支持，T opic通常需要人工来创建，部署和维护较一般消息队列成本更高
定位于日志传输、存在消息丢失的肯能、消息乱序 3、消息发送错误无重试 2、4 RocketMQ RockerMq 是阿里公司中间件团队参考Kafka思想，用Java语言实现的消息传输系统 优点： 1、较高性能，单机写入TPS单实例约7万条/秒 2、容错，多种集群模式、可以解决容错问题 3、消息重试发送 4、顺序消息可以严格执行 缺点： 1、消息重复、消费端需要做去重操作 2、5 选用结论 从项目业务与团队技术偏向考虑，我们应该需要一种数据安全性比较高，保证每个消息都会被执行；有容错机制、支持集群模式高可用；性能不错，可以在毫秒级处理消息；支持顺序消息的消息中间件，RockerMq 可以满足这些要求。 3、RockerMq简介 3、1 RockerMq 产品介绍 参考阿里公司提供的《RocketMQ 开发指南》，最新版针对v3.2.4 3、2 RockerMq集群 3、2、1 部署方式 Rockermq共有四种部署方式，分别是： 1、单个Master 一旦Broker 重启或者宕机时，会导致整个服务不可用 2、多Master 模式 一个集群无Slave，全是Master，例如2 个Master 戒者3 个Master 优点： 1、配置简单， 2、容错，单个Master 宕机或重启维护对应用无影响，在磁盘配置为RAID10 时，即使机器宕机不可恢复情况下，由于RAID10 磁盘非常可靠，在同步刷盘时消息不会丢，异步刷盘丢失少量消息， 3、性能最高。
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 调用从队列上接收数据。
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))
中间件消息通信技术概要
中间件消息通信技术概要 一、中间件 中间件，就是介于应用系统与系统软件之间的一类软件，它使用系统软件所提供的基础功能，衔接于应用系统的不同部分，能够达到资源共享和功能共享的目的。 消息中间件，是中间件众多产品分类中一个重要部分。它能够适用于任何需要进行网络通信的系统，负责建立网络通信的通道，进行数据或文件发送。消息中间件的一个重要作用是可以实现跨平台操作，为不同操作系统上的应用软件集成提供服务。 二、几种通信技术的比较 1、CPI-C CPI-C是一种同步对话通信模式。参加通信的一方发起一次对话，同时控制信息流动。数据既可以由发送者传递到接受者，也可以反向流动。 参加通信的两个程序需要跟踪对话的状态，如果异常发生导致连接中断，则需要发送方重建并恢复这次通话。通信双方既可以处于主从地位，也可以处于对等地位。也就是说，CPI-C既支持客户端－服务器环境，也支持对等通信方式。 虽然CPI-C在一般情况下是一种同步通信类型，但是在一定环境中，如CIC S，可以通过“临时数据队列”实现一定程度的异步。 TCP/IP，SNA都支持CPI-C。 由于需要应用程序参与错误的检测与恢复，CPI-C的编程接口相当复杂。
2、RPC RPC，即远程过程调用，也是一种同步，对话方式的类型。一个调用程序向服务器提成申请，该调用被负责通信的转接器发往远端系统。调用者与被调用者关系是固定的，很难实现对等通信。 与CPI-C一样，通信错误需要应用程序自己维护。另外在申请服务得到响应之前，服务申请者被阻隔，这不仅是应用的瓶颈所在，更有可能遭受拒绝式服务攻击。 3、MQI(Message Queue Interface) 消息队列接口为程序提供了一种异步通信方式。一个程序以一个队列作为中转与另一个程序相互通信，这个队列向对于该程序而言既可以是本地，也可以是远程。当程序A与程序B进行通信时，A只需要将消息放入一条与B相通信的队列即可，至于消息何时，以何种协议，何种方式到达程序B与A没有关系。底层的通信细节被接口所覆盖，甚至通信错误的恢复也由队列管理器代劳了，应用程序自身感受不到通信的发生。 由于通信方式和使用的协议无关，因而可以使用各种标准协议，比如TCP/I P，SNA或者其他局域网协议。 当程序A向B发送消息的时候，程序B不需要处于运行状态，消息队列负责了消息的转达。而且一个程序可以通过不同的队列与多个程序进行通信。
ACE-[消息队列和消息块]
消息队列 线程安全的消息排队机制 如果MT_Synch被用于实例化Message_Queue，所有的公共方法都将是线程安全的，但同时也带来相应的开销。相反，如果Null_Synch类用于实例化Message_Queue，所有公共方法都不是线程安全的，同时也就没有额外的开销。只有一个线程，消息队列的模板同步参数被设置为空（ACE_NULL_SYNCH）。 如果队列中没有数据可用，它就进入休眠状态。如果有其他任务将消息插入它的队列，它就会苏醒过来，从队列中拾取数据并处理 它。因而，在这种情况下，接收任务将从发送任务那里接收消息，并以应用特定的方式作出反馈。（上面所说的前提是在 ACE_MT_SYNCH 下）如果是ACE_Null_Synch就没有这种相应的唤醒机制了！！ ACE 中的每个任务(ACE_Task)都有一个底层消息队列(ACE_Message_Queue)。这个消息队列被用作任务间通信的一种方法。当一个任务想要与另一任务“谈话”时，它创建一个消息，并将此消息放入它想要与之谈话的任务的消息队列。接收任务通常用 getq()从消息队列里获取消息。 ACE_Activation_Queue： 默认采用ACE_Message_Queue< ACE_MT_SYNCH > 保存数据 1. ACE_Method_Request * ACE_Activation_Queue::dequeue (ACE_Time_Value *tv = 0);如果tv没有值；则阻塞如果tv有 值，超时返回EWOULDBLOCK。 2. ACE_Message_Queue 采用双向链表组织结构 1. 指定队列是否同步化（ACE_MT_SYNCH 、 ACE_NULL_SYNCH） 2. 流控 统计所有block的字节总数cur_bytes_，在新消息放到队列之前，判断字节总数是否高于高水位标（缺省高低水
嵌入式操作系统核原理开发(消息队列)
嵌入式操作系统内核原理和开发（消息队列） 消息队列是线程交互的一种方法，任务可以通过消息队列来实现数据的沟通和交换。在嵌入 式系统上，这可以说这是用的最多的一种方法。通过消息队列，无论是发送者，还是接受者 都可以循环地处理各种消息。而我们知道，存储消息最好的方式就是循环队列，如果消息已 满，那么发送者可以把自己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; 上面的代码中有两段数据结构，第一段主要表示循环队列的内容，其中包括了队列首地
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。
posix消息队列使用全面介绍
POSIX消息队列是linux进程间通信的重要方式，下面按照创建，使用，关闭的顺序讲述了POSIX消息队列的使用方法： 创建POSIX消息队列： mq_open #include
利用消息队列实现多进程通信过程
课程名称：Unix课程设计 设计题目：利用消息队列实现多进程通信过程 姓名： 专业：网络工程 班级： 学号： 计算机科学与技术学院 网络系 2013 年12月30 日
一、选题背景 在UNIX程序设计中消息队列是使用频率最高的几个对象之一，它常应用于对等进程间的通信和客户—服务器之间的通信。 采用消息队列作为货物托运渠道可以弥补以下缺陷： （1）消息队列是一种先进先出的队列型数据结构，可以保证先送的货物先到达，后送的货物后到达，避免了插队现象。 （2）消息队列将输出的信息进行了打包处理，这样就可以保证以每个消息为单位进行接收了。 （3）消息队列还可以将货物进行分类服务，标记各种类别的服务，这样就可以根据货物类别分别出货。 消息队列是IPC对象的一种与同样提供先进先出服务的管道相比，它有如下特点： （1）消息队列提供了消息的自动拆分功能，同时不能接收两次发送的消息。 （2）消息队列提供了不完全随机读取的服务，引入消息类型后，一个消息队列在逻辑上可以化身为多个不同消息类型的链表，用户可以自主选择接收某条逻辑链表上的消息，而不必依次接收队列的首条消息。 （3）消息队列提供了完全异步的读写服务。 基于以上背景，我们发现利用消息队列实现进程间的通信可以为我们提供方便，也会是通信效率更为提高。 二、设计思路 可以采用客户-服务器结构，其中服务器端实现各个用户的登录并存储相关信息，客户端通过服务器端获取当前登录用户信息，然后各客户进程通过消息队列实现双向通信。 编程实现两个进程间的通信，一个server（服务器）进程，一个client（客户）进程。 在client（客户）进程下选择注册或者登陆。 若是注册，则server（服务器）进程分给该客户一个新的登陆账号。多个客户的账号存储在register.txt文件中。 若是选择登陆，登陆成功后服务器进程会显示登陆成功，否则显示登陆失败。登陆后输入你要发送消息的对方的账号，输入账号后，服务器方显示该账号是否合理，如合理，即可实行通信。 三、主要问题的解决方法和关键技术 实现密码格式登录与注册，通过帐号显示用户名，显示发送消息的日期 四、程序流程图
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
消息队列介绍及原理
消息队列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应用提供了广泛及一致的模式。
单消息队列完成客户服务器进程之间的双向通信
哈尔滨理工大学《UNIX程序设计》 课程设计报告 题目：单消息队列完成客户/服务器进程之间的双向通信院系：计算机科学与技术学院网络工程系 班级学号： 姓名： 指导教师：郭锦兰 成绩： 2013年12月23日
第1章绪论 ..................................................................................................- 1 - 1.1 选题内容 .........................................................................................- 1 - 1.2 相关技术 .........................................................................................- 1 - 第2章系统设计 ..........................................................................................- 1 - 2.1系统介绍 .........................................................................................- 2 - 2.2实现原理 ..........................................................................................- 3 - 2.3主要问题的解决方法及关键技术 (5) 2.4 流程图 (6) 第3章系统实现 (7) 3.1客户端截图 (7) 3.2服务器端截图 (8) 结论 (9) 附录 (10) 附录A 核心程序代码 (10)
Posix消息队列
Linux3+1暑期学习总结三(Posix消息队列) －－－王晶晶 一，消息队列简介： 消息队列可以看作是一个消息连表。它具有随内核的持续性，即当使用该消息队列的进程结束，或者已关闭该消息队列，该队列中的消息不会随之消失，只有在内核重新初始化，即计算机重启之后才会消失，因此称为随内核的持续性，这点也是与管道和FIFO的区别。消息队列的另一个特性是，在某一个进程往消息队列写消息之前不需要另外某个进程在该消息队列上等待消息的到达，即不会像管道个FIFO那样，如果往管道或者FIFO中些数据时，如果没有一个进程已经将读端打开，那么写操作会被阻塞。当然，如果从消息队列读取数据时，消息队列为空是会阻塞的。 每个消息都是一条记录，它有发送者赋予一个优先权，值越大优先级越高。 下图为一个消息队列可能的布局： 该链表的头中含有当前队列的两个属性：队列中允许的最大消息数，每个消息的最大大小。 二，相关函数解释： 1．m q_open 所在头文件:#include
mode_t mode, struct mq_attr *attr)； 函数功能：创建消息队列。 参数说明：name为消息队列的名字，根据消息队列的规则，为了更好的可移植性，该名字必须以…／?开头，创建一个消息队列的时候无须路径，给出名字就好，其存放位置可有自己指定(创建前后都可以，下面会讲到)。 oflag：为O_RDONLY（只读），O_WRONLY(只写)，O_RDWR(可读可写)之一，可能安位或上O_CREATE,O_EXCL（当消息已存在时，返回EEXIST错误到errno中），O_NONBLOCK(设置非阻塞)。 mode和attr参数是可选，但是当实际操作是创建一个新队列时，即O_CREATE已指定，且要求创建的消息队列不存在，mode和attr参数是需要的。 mode：表示创建消息对列的权限。由 S_IRUSR,S_IWUSR,S_IXUSR,S_IRGRP,S_IWGRP,S_IXGRP,S_IROTH,S_IWOTH, S_IXOTH相或组成或者写成0777(表示rwxrwxrwx)等用八进制表示也可以。 attr:在linux内核源代码中struct_mqattr定义的源代码如下： 存放消息队列的属性。其中mq_flags为0，表示阻塞，为O_NONBLOCK为非阻塞。 函数返回值：在内核源代码中mqd_t类型的定义如下： typedef __kernel_mqd_t mqd_t; typedef int __kernel_mqd_t; 若创建成功则返回消息队列的描述符，否则返回－1。 2．mq_close函数：
消息队列的使用方法
uCOS II 消息队列的使用方法 需在以下文件中配置如下内容： 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