消息队列

Kafka概述 a distributed streaming platform Kafka架构和核心概念 producer, 生产者，生产馒头。 consumer, 消费者，吃馒头。 broker, 篮子。 topic, 主题，给馒头带一个标签，topica的馒头是给你吃的，topicb的馒头是给你弟弟吃。 Zookeeper集群部署 安装包解压 ， 1 tar -xzvf zookeeper-3.4.5.tar.gz -C / export /servers zookeeper配置文件修改 ， 1 cp zoo_sample.cfg zoo.cfg 2 vi zoo.cfg 3 #数据目录. 可以是任意目录,其中的dataDir目录和dataLogDir需要提前建立好 4 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会在很大程度上影响系统的性能。 5 dataDir=/ export /servers/data/zookeeper 6 #log目录, 同样可以是任意目录. 如果没有设置该参数, 将使用和dataDir相同的设置，其中的dataDir目录和dataLogDir需要提前建立好 7 #注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能

rabbitmq是目前消息队列比较热门的使用技术，这里它和其他几类技术的对比本文就不做赘述了。本文主要讲述在Docker下如何部署rabbitmq分布式集群。本文不讲述docker及rabbitmq镜像的安装下载。 一、前期准备 本文以两台服务器作为示例。服务器A的IP为192.168.1.10，服务器B的IP为192.168.1.11。为了后期管理更多docker配置方便，分别在A，B两台服务器里面新建docker目录，其结构示例如下： cd /home/user/ mkdir docker cd docker mkdir rabbitmq cd rabbitmq touch hosts vim hosts 进入刚创建好的hosts文件配置服务器映射，编辑好以后wq保存退出 192.168.1.10 rabbit1 192.168.1.11 rabbit2 二、在A服务器中启动已经下载好的rabbitmq镜像 docker run -d --privileged=true --net host --hostname rabbit1 --name rabbitmq1 -v /home/user/docker/rabbitmq:/var/lib/rabbitmq -v /home/user/docker/rabbitmq/hosts:/etc/hosts -e RABBITMQ

这两天研究了一下，OpenStack的工作原理，并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先，OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现，消息由RabbitMQ作为中间件转发，以一种RPC（Remote Process Call）的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块，上图中是一个逻辑结构，可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机，Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例，每一个Nova服务都会在初期建立两个队列，两个队列同时与相同的exchange（名称叫做Nova、类型为Topic）绑定，但是二者的RoutingKey不同也就是Topic不同，格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE，其二者功能也有所不同，并且由于采用RPC结构，所以当操作完成，结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想，具体图示如下：

这两天研究了一下，OpenStack的工作原理，并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先，OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现，消息由RabbitMQ作为中间件转发，以一种RPC（Remote Process Call）的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块，上图中是一个逻辑结构，可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机，Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例，每一个Nova服务都会在初期建立两个队列，两个队列同时与相同的exchange（名称叫做Nova、类型为Topic）绑定，但是二者的RoutingKey不同也就是Topic不同，格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE，其二者功能也有所不同，并且由于采用RPC结构，所以当操作完成，结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想，具体图示如下：

本篇文章是由本人阅读NOVA源码过程中的心得、 RabbitMQ 的官方文档以及网上的一些资料整理总结而成的，也为了方便以后对这部分内容的复习。 NOVA是OpenStack系统的核心模块，主要负责虚拟机实例的生命周期管理、网络管理（前几个版本）、存储卷管理（前几个版本）、用户管理以及其他相关云平台管理功能，在能力上类似于Amazon EC2和Rackspace Cloud Servers。 消息队列（Queue ）与数据库（Database） 作为Nova总体架构中的两个重要组成部分，二者通过系统内消息传递和信息共享的方式实现任务之间、模块之间、接口之间的异步部署，在系统层面大大简化了复杂任务的调度流程与模式，是整个OpenStack Nova系统的核心功能模块。终端用户（DevOps、Developers和其他OpenStack组件）主要通过Nova API实现与OpenStack系统的互动，同时Nova守护进程之间通过消息队列和数据库来交换信息以执行API请求，完成终端用户的云服务请求。 Nova采用无共享、基于消息的灵活架构，意味着Nova的组件有多种安装方式，可以将每个Nova-Service模块单独安装在一台服务器上，同时也可以根据业务需求将多个模块组合安装在多台服务器上。 1. RabbitMQ OpenStack Nova系统目前主要采用 RabbitMQ

一、前言 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用MySQL作为消息存储媒介，支持水平扩容。为了进一步降低成本，阿里中间件团队认为Notify可进一步优化。 2011年初，Linkedin开源了kafka, 阿里中间件团队在对kafka做了充分的review之后，被kafka的无限消息堆积能力、高效的持久化速度深深吸引，但同时发现kafka主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下，还有若干特性不满足。因此，阿里中间件团队基于Java重新编写了RocketMQ，定位于不仅限于日志场景的可靠消息传输。 目前，RocketMQ在阿里集团被广泛应用于订单、充值、交易、流计算、消息推送、日志流式处理、binlog分发等场景。 二、RocketMQ与kafka的不同 1、数据可靠性 RocketMQ：支持异步实时刷盘、同步刷盘、同步复制、异步复制。 kafka：使用异步刷盘方式，异步复制/同步复制。 总结： 1、RocketMQ支持kafka所不具备的“同步刷盘”功能，在单机可靠性上比kafka更高，不会因为操作系统Crash而导致数据丢失。 2、kafka的同步replication理论上性能低于RocketMQ的replication，这是因为kafka的数据以partition为单位，这样一个kafka实例上可能多上百个partition

RabbitMQ是一个消息代理：它接受和转发消息。你可以把它想象成一个邮局：当你把你想寄出的邮件放进一个邮箱里时，你可以确信邮件的收件人最终会收到邮件。在这个类比中，RabbitMQ是一个邮箱、一个邮局和一个邮递员。 RabbitMQ与邮局的主要区别在于，它不处理纸张，而是接受、存储和转发二进制的数据信息块。 RabbitMQ分为三大主体：生产者、消息队列、消费者。 请注意，生产者、消费者和代理不必驻留在同一主机上；事实上，在大多数应用程序中，它们不必驻留在同一主机上。应用程序也可以既是生产者又是消费者。 AMQP协议 Broker：接收和分发消息的应用，消息中间件的系统。 Virtual host：同一个RabbitMQ可以划分出多个虚拟主机，不同用户可以在不同的虚拟主机上创建自己的EXChange，queue。 Connection：publisher/consumer和broker之间的TCP连接，通过Socket进行获取inpustream和outputstream。连接断开操作只会在client端进行，broker不会断开连接。除非网络中断或者broker服务端故障。 Channel：信道，如果每一次访问RabbitMQ都建立一次连接，在消息量大的情况下建立TCP，Connection很消耗资源，而且效率很低。Channel是在Connection内部建立连接逻辑

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

本节内容： RabbitMQ介绍 RabbitMQ运行原理 RabbitMQ重要术语 三种ExchangeType RabbitMQ集群种类 集群基本概念 镜像模式部署集群 一、RabbitMQ介绍 消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶。 或许你正在考虑进行数据投递，非阻塞操作或推送通知。或许你想要实现发布／订阅，异步处理，或者工作队列。所有这些都属于消息系统的模式。 RabbitMQ是一个消息代理，一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息再传输过程中的安全。 RabbitMQ是一个在AMQP协议标准上完整的、可复用的企业消息系统。它遵循Mozilla Public License开源协议，采用Erlang语言实现的工业级的消息队列。 二、RabbitMQ运行原理 RabbitMQ的两大核心组件是Exchange和Queue，以下是它的运行原理图： 三、RabbitMQ重要术语 Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程。 Vitual Host: 这是一个虚拟概念，类似于权限控制组，一个Vitual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Vitual Host。 Exchange: 接收生产者发送的消息

目录 kclient消息中间件 kclient-processor top.ninwoo.kclient.app.KClientApplication top.ninwoo.kclient.app.KClientController top.ninwoo.kclient.app.handler.AnimalsHandler top.ninwoo.kclient.app.domain 总结 kclient-core top.ninwoo.kafka.kclient.boot.KClientBoot createObjectHandler createObjectsHandler createDocumentHandler createBeanHandler createBeansHandler invokeHandler 生产者和消费者创建方法 小结 top.ninwoo.kafka.kclient.boot.KafkaHandlerMeta top.ninwoo.kafka.kclient.core.KafkaProducer top.ninwoo.kafka.kclient.core.KafkaConsumer init() initAsyncThreadPool() initKafka startup() AbstractMessageTask