转自：http://blog.csdn.net/yfkiss/article/details/17348693
代码案例
http://blog.csdn.net/ganglia/article/details/12651891
http://blog.csdn.net/hxpjava1/article/details/19160665
基于HTTP协议的轻量级开源简单队列服务：HTTPSQS：http://blog.s135.com/httpsqs/
1. 引言
互联网公司的日志无处不在，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的场景。
2. 介绍
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. Producer根据指定的partition方法（round-robin、hash等），将消息发布到指定topic的partition里面
2. kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
3. Consumer从kafka集群pull数据，并控制获取消息的offset
3. 设计
ThroughPut
High Throughput是kafka需要实现的核心目标之一，为此kafka做了以下一些设计：
1）数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
2）zero-copy：减少IO操作步骤
3）数据批量发送
4）数据压缩
5）Topic划分为多个partition，提高parallelism
load balance&HA
1) producer根据用户指定的算法，将消息发送到指定的partition
2) 存在多个partiiton，每个partition有自己的replica，每个replica分布在不同的Broker节点上
3) 多个partition需要选取出lead partition，lead partition负责读写，并由zookeeper负责fail over
4) 通过zookeeper管理broker与consumer的动态加入与离开
pull-based system
由于kafka broker会持久化数据，broker没有内存压力，因此，consumer非常适合采取pull的方式消费数据，具有以下几点好处：
1）简化kafka设计
2）consumer根据消费能力自主控制消息拉取速度
3）consumer根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等
Scale Out
当需要增加broker结点时，新增的broker会向zookeeper注册，而producer及consumer会根据注册在zookeeper上的watcher感知这些变化，并及时作出调整。