Apache Artemis是apache的一个新的消息系统， 这个消息系统是来源于 redhat的 “异步消息系统 HornetQ”
HornetQ的相关资料有如下：
http://wenku.baidu.com/view/2f19b1557fd5360cba1adbd9.html?from=search
http://activemq.apache.org/artemis/ 项目的注意
http://activemq.apache.org/artemis/download.html 下载页面
另外 可以参考 HornetQ的相关资料， 目前同 HornetQ还有很大的相似性
选择他的Artemis的考虑是， 他是中等成熟的 消息系统， 功能够用， 代码少， 阅读方便， 便于理解， 这样有了问题才好 进行相关的处理工作。
而 activemq 代码太庞大了， 功能太多， 想彻底弄清楚要费非常大力气
而apache Apollo
… 阅读全文基于Spark通用计算平台，可以很好地扩展各种计算类型的应用，尤其是Spark提供了内建的计算库支持，像Spark Streaming、Spark SQL、MLlib、GraphX，这些内建库都提供了高级抽象，可以用非常简洁的代码实现复杂的计算逻辑、这也得益于Scala编程语言的简洁性。这 里，我们基于1.3.0版本的Spark搭建了计算平台，实现基于Spark Streaming的实时计算。
我们的应用场景是分析用户使用手机App的行为，描述如下所示：
Spark Streaming介绍
Spark Streaming提供了一个叫做DStream（Discretized Stream）的高级抽象，DStream表示一个持续不断输入的数据流，可以基于Kafka、TCP Socket、Flume等输入数据流创建。在内部，一个DStream实际上是由一个RDD序列组成的。Sparking Streaming是基于Spark平台的，也就继承了Spark平台的各种特性，如容错（Fault-tolerant）、可扩展 （Scalable）、高吞吐（High-throughput）等。
在Spark Streaming中，每个DStream包含了一个时间间隔之内的数据项的集合，我们可以理解为指定时间间隔之内的一个batch，每一个batch就 构成一个RDD数据集，所以DStream就是一个个batch的有序序列，时间是连续的，按照时间间隔将数据流分割成一个个离散的RDD数据集，如图所 示（来自官网）：
我们都知道，Spark支持两种类型操作：Transformations和Actions。Transformation从一个已知的RDD数据集经过 转换得到一个新的RDD数据集，这些Transformation操作包括map、filter、flatMap、union、join等，而且 Transformation具有lazy的特性，调用这些操作并没有立刻执行对已知RDD数据集的计算操作，而是在调用了另一类型的Action操作才 会真正地执行。Action执行，会真正地对RDD数据集进行操作，返回一个计算结果给Driver程序，或者没有返回结果，如将计算结果数据进行持久 化，Action操作包括reduceByKey、count、foreach、collect等。关于Transformations和Actions 更详细内容，可以查看官网文档。
同样、Spark Streaming提供了类似Spark的两种操作类型，分别为Transformations和Output操作，它们的操作对象是DStream，作 用也和Spark类似：Transformation从一个已知的DStream经过转换得到一个新的DStream，而且Spark Streaming还额外增加了一类针对Window的操作，当然它也是Transformation，但是可以更灵活地控制DStream的大小（时间 间隔大小、数据元素个数），例如window(windowLength, slideInterval)、countByWindow(windowLength, slideInterval)、reduceByWindow(func, windowLength, slideInterval)等。Spark Streaming的Output操作允许我们将DStream数据输出到一个外部的存储系统，如数据库或文件系统等，执行Output操作类似执行 … 阅读全文
4.启动Broker，设置对应的NameServer
可以查看sameple中的quickstart源码 1.Consumer 消息消费者
/**
* Consumer，订阅消息
*/
public class Consumer {
public static void main(String[] args)
… 阅读全文RocketMQ是一款分布式、队列模型的消息中间件，具有以下特点：
看完其实还是不懂，所以我们先了解几个基本概念：
| Producer | 消息生产者，负责产生消息，一般由业务系统负责产生消息 |
| Consumer | 消息消费者，负责消费消息，一般是后台系统负责异步消费 |
| Push Consumer | Consumer的一种，应用通常向Consumer对象注册一个Listener接口，一旦收到消息，Consumer对象立刻回调Listener接口方法 |
| Pull Consumer | Consumer的一种，应用通常主动调用Consumer的拉消息方法从Broker拉消息，主动权由应用控制 |
| Producer Group | 一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致 |
| Consumer Group | 一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致 |
| Broker | 消息中转角色，负责存储消息，转发消息，一般也称为Server。 |
| 长连接 | 在页面嵌入一个隐藏的Iframe，将这个隐藏Iframe的src属性设置为对一个长连接的请求或是采用xhr请求，服务器端就源源不断的向客户端输入数据。 |
RocketMQ是一款分布式、队列模型的消息中间件，具有以下特点：能够保证严格的消息顺序
来源：http://www.changeself.net/archives/rocketmq%E5%85%A5%E9%97%A8%EF%BC%881%EF%BC%89.html
研究kafka中， 集群批准好了， 用kafka的 控制台例子收发消息都成功了， 想用java进行一下测试，但是怎么弄都没好用， 在网络搜索了例子测试一下。
kafka官方给的示例并不是很完整，以下代码是经过我补充的并且编译后能运行的。
http://kafka.apache.org/documentation.html#highlevelconsumerapi 等
Producer Code
import java.util.*;
import kafka.message.Message;
import kafka.producer.ProducerConfig;
import kafka.javaapi.producer.Producer;
import kafka.javaapi.producer.ProducerData;
public class ProducerSample {
public static void main(String[] args) {
ProducerSample ps = new ProducerSample();
Properties props = new … 阅读全文
MQTT（Message Queue Telemetry Transport）,遥测传输协议，提供订阅/发布模式，更为简约、轻量，易于使用，针对受限环境（带宽低、网络延迟高、网络通信不稳定），可以简单概括为物联网打造，官方总结特点如下：
1.使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
2. 对负载内容屏蔽的消息传输。
3. 使用 TCP/IP 提供网络连接。
4. 有三种消息发布服务质量：
“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
“至少一次”，确保消息到达，但消息重复可能会发生。
“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
5. 小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。
6. 使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品 和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
—– ZMQ的学习和研究
引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是 “成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功。但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接 字之上的一 层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。”
近几年有关”Message Queue”的项目层出不穷，知名的就有十几种，这主要是因为后摩尔定律时代，分布式处理逐渐成为主流，业界需要一套标准来解决分布式计算环境中节点之间 的消息通信。几年的竞争下来，Apache基金会旗下的符合AMQP/1.0标准的RabbitMQ已经得到了广泛的认可，成为领先的MQ项目。
与RabbitMQ相比，ZMQ并不像是一个传统意义上的消息队列服务器，事实上，它也根本不是一个服务器，它更像是一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象为统一的API接口。
阅读了ZMQ的Guide文档后，我的理解 是，这是个类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏 蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。
在集群对外提供服务的过程中，我们有很多的配置，需要根据需要随时更新，那么这个信息如果推动到各个节点？并且保证信息的一致性和可靠性？本文在介 绍ZMQ基本理论的基础上，试图使用ZMQ实现一个配置分发中心。从一个节点，将信息无误的分发到各个服务器节点上，并保证信息正确性和一致性。
ZMQ提供了三个基本的通信模型，分别是“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”,我们从这三种模式一窥ZMQ的究竟
由Client发起请求，并等待Server回应请求。请求端发送一个简单的hello，服务端则回应一个world。请求端和服务端都可以是 1:N 的模型。通常把 1 认为是 Server ，N 认为是Client … 阅读全文
互联网够公司的日志无处不在，web日志，js日志，搜索日志，监控日志等等。对于这些日志的离线分析 （Hadoop），wget&rsync虽然人力维护成本较高，但可以满足功能行需求。但对于这些日志的实时分析需求（例如实时推荐，监控系 统），则往往必须要引入一些“高大上”的系统。
传统的企业消息系统（例如WebSphere）并不是非常适合大规模的日志处理系统，理由如下：
1) 过于关注可靠性，这些可靠性增加了系统实现&API的复杂度，而在日志处理过程中，丢失几条日志常常“无伤大雅”
2) 包括API，scale及消息缓冲的设计理念都不适合Hign Throughput的日志处理系统
针对这些问题，近些年各个公司都做了一些自己的日志收集系统，例如：Facebook的Scribe、Yahoo的data highway，Cloudera的Flume，Apache的Chukwa，百度的BigPipe，阿里的RocketMQ。
Kafka是LinkedIn开发并开源出来的一个高吞吐的分布式消息系统。其具有以下特点：
1) 支持高Throughput的应用
2) scale out：无需停机即可扩展机器
3) 持久化：通过将数据持久化到硬盘以及replication防止数据丢失
4) 支持online和offline的场景。
kafka使用scala开发，支持多语言客户端（c++、java、python、go等）其架构如下[2]：
Producer：消息发布者
Broker：消息中间件处理结点，一个kafka节点就是一个broker
Consumer：消息订阅者
kafka的消息分几个层次：
1) Topic：一类消息，例如page view日志，click日志等都可以以topic的形式存在，kafka集群能够同时负责多个topic的分发
2) Partition： Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。
3) Message：消息，最小订阅单元
具体流程：
1. … 阅读全文