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 介绍 消息队列（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使用场景 ?异步通信 有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 ?解耦 降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 ?冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 ?扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。 ?过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 ?可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 ?顺序保证 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。 ?缓冲 在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。 以调节系统响应时间。 ?数据流处理 分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
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消息队列是linux进程间通信的重要方式，下面按照创建，使用，关闭的顺序讲述了POSIX消息队列的使用方法： 创建POSIX消息队列： mq_open #include
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
通过认证服务的学习，我们可以以不同的身份访问企业云平台，可以通过研发部的账户登录研发部，可以通过业务部访问业务部的资源，也可以通过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消息和消息队列的原理与应用方法。分享给大家供大家参考。具体分析如下： 与基于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。
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）简介及其使用 利用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） ―消息‖是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。 消息被发送到队列中。―消息队列‖是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
进程间通信之消息队列 一．原理讲解 消息队列(也叫报文队列)，它是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)
ORACLE OSB消息总线原理、作用、功能 技术方案 一、概述 消息交换总线技术是为了实现企业数据共享和应用集成，提供一种基于企业服务总线(ESB)的信息共享交换平台。该技术采用面向服务体系结构(SOA)的设计思想，以信息共享为目标，具有松散耦合的特点，实现了"集中式管理、分布式运行"的工作模式。通过设计标准的适配器组件，实现各种数据库和应用系统之间的数据共享与交换，能有效实现企业中信息共享，并具有良好的可扩展性和可靠性。 ORACLE的OSB总线包括ESB（Enterprise Service Bus）和 WSM（Web Service Management）两大部分，是ORACLE公司的消息交换总线产品。ESB包括MOM, ORBs, RPCs, WebServices功能的新型、综合类型中间件，通过配置集成；WSM包括服务管理，消息跟踪两个部分。使用OSB可以很容易的将企业已有的对外功能集成进来，并且能够集成和开发出来新的功能。 OSB的下载、安装、使用、实验、培训课件请参考以下附件： 二、服务总线 使用OSB服务总线，可以实现以下功能： 1、SOA中的服务中介
高速中介 一次连接 松散耦合 动态扩展 交易处理可视化 敏捷架构 企业范围内的可重用 集中化管理 控制风险 改善总所有成本（TCO） 2、服务的代理 支持多种协议格式 Web Services 的处理 完全支持相应的Web Services (WSDL, SOAP包) 和non-SOAP包的消 息 多种通讯方式 请求/响应(同步/异步)，异步消息队列，一对多的发布
组合方式(例如： sync-to-async 桥) 3、支持消息类型 OSB支持下列消息类型： JMS with headers Email (无论是否带有附件) MFL (Message Format Language) Raw data Text SOAP( 无论是否带有附件） XML （无论是否带有附件） 4、访问目标透明(Location Transparency) OSB可以将服务与位置变化隔离。
消息队列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应用提供了广泛及一致的模式。
软件英才网软件行业驰名招聘网站 嵌入式操作系统内核原理和开发（消息队列） 消息队列是线程交互的一种方法，任务可以通过消息队列来实现数据的沟通和交换。在嵌入 式系统上，这可以说这是用的最多的一种方法。通过消息队列，无论是发送者，还是接受者 都可以循环地处理各种消息。而我们知道，存储消息最好的方式就是循环队列，如果消息已 满，那么发送者可以把自己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;
Asiainfo-Linkage, Inc., 数据消息中间件介绍 DMQ CUC SRD1-UAP-PSO
修订文档历史记录 机密 Asiainfo-Linkage, Inc., 第 2 页共13 页
1背景 目前几个流行的消息中间件产品分析： ◆Apache的ActiveMq我们的几个产品都在使用，存在几个方面问题：使 用复杂、维护不方便，容易出故障等，比如， 需要熟悉JMX规范，了解各种接口定义； 产品提供的web监控页面不直观，需要做深入了解后，才明白。 监控mq内部运行情况，需要根据提供的接口进行代码开发； ◆IBM的MQ不仅收费，而且使用更复杂，bug多，且不稳定。服务开通 系统以前使用过，后来放弃使用。 ◆微软MSMQ，从网络上大众使用的反馈也不好，不稳定。 所以计划自己开发一个简单的队列处理器，简称：DMQ。 2目标 希望解决： 1.提供稳定的消息中间件； 2.使用简单，部署、配置很容易； 3.更方便维护，通过简单的sql语句即可查询、操作队列数据，以及页面展示 等； 4.可以根据业务优先级定义，分配不同的队列，并按优先级获取队列数据； 5.为今后消息中间件使用提供产品复用 3功能实现 结合BSS等业务系统具体情况：有数据库、使用人员都熟悉数据库等，因此，创建队列数据到自己的数据库中。方便队列数据的查询、监控以及队列数据维护。 机密 Asiainfo-Linkage, Inc., 第 3 页共13 页
3.1 目前MQ使用情况 3.1.1BSS-OCS接口平台 3.1.2UIP平台 机密 Asiainfo-Linkage, Inc., 第 4 页共13 页