RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上。
kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。
1、 RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka
2、 Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
3、 Kafka的性能（吞吐量、tps）比RabbitMq要强
kafka 很多说不需要安装zk的是因为他们都使用了kafka自带的zk
至于kafka为什么使用zk，你首先要知道zk的作用, 作为去中心化的集群模式。
需要要消费者知道现在那些生产者（对于消费者而言，kafka就是生产者）是可用的。
如果没了zk消费者如何知道呢？如果每次消费者在消费之前都去尝试连接生产者测试下是否连接成功，效率呢？
所以kafka需要zk，在kafka的设计中就依赖了zk了。
基本概念
Kafka是Linkedin于2010年12月份开源的分布式、高吞吐量 的订阅、发布 消息系统，它主要用于处理活跃的流式数据。活跃的流式数据在web网站应用中非常常见，这 些数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。 这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。
传统的日志分析系统提供了一种离线处理日志信息的可扩展方案，但若要进行实时处理，通常会有较大延迟。而现有的消（队列）系统能够很好的处理实时或 者近似实时的应用，但未处理的数据通常不会写到磁盘上，这对于Hadoop之类（一小时或者一天只处理一部分数据）的离线应用而言，可能存在问题。 Kafka正是为了解决以上问题而设计的，它能够很好地离线和在线应用
Kafka 分布式消息队列 类似产品有JBoss、MQ
一、由Linkedln 开源，使用scala开发，有如下几个特点：
（1）高吞吐
（2）分布式
（3）支持多语言客户端 （C++、Java）
二、组成: 客户端是 producer 和 consumer，提供一些API，服务器端是Broker，客户端提供可以向Broker内发布消息、消费消息，服务器端提供消息的存储等功能
Kafka 特点是支持分区、分布式、可拓展性强
三、Kafka 的消息分几个层次
(1)Topic 一类主题
(2)Partition 默认每个消息有2个分区，创建Topic可以指定分区数，1天有 1亿行可以分8个分区，如果每天几十万行就一个分区吧
(3)Message 是每个消息
四、数据处理流程
1.生产者 生产消息、将消息发布到指定的topic分区
2.kafka 集群接收到producer发过来的消息后，将其持久化到硬盘，可以指定时长，而不关注消息是否被消费
3.consumer从kafka集群pull或push方式，并控制获取消息的offset偏移量，consumer重启时需要根据offset开始再次消费数据，consumer自己维护offset
五、kafka如何实现高吞吐量
1.充分利用磁盘的顺序读写
2.数据批量发送
3.数据压缩
4.Topic划分多个partition
六、kafka 如何实现load balance & HA
1）producer 根据用户指定的算法，将消息发送到指定的partition
2）存在多个partition，每个partition存在多个副本replica，每个replica分布在不同的broker节点上
3）每个partition需要选取lead partition，leader partition负责读写，并由zookeeper负责fail over 快速失败
4）通过zookeeper管理broker与consumer的动态加入与离开
七、扩容
当需要增加broker节点时，新增的broker会向zookeeper注册，而producer及consumer会根据zookeeper上的watcher感知这些变化，并及时作出调整
kafka的工作方式和其他MQ基本相同，只是在一些名词命名上有些不同。为了更好的讨论，这里对这些名词做简单解释。通过这些解释应该可以大致了解kafka MQ的工作方式。
- Producer （P）：就是往kafka发消息的客户端
- Consumer （C）：从kafka取消息的客户端
- Topic （T）：可以理解为一个队列
- Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个 topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个CG只会把消息发给该CG中的一个 consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还 可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
- Broker （B）：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
- Partition（P）：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
分布式(Distribution)
Log的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。 根据配置每个分区还可以复制到其它服务器作为备份容错。
每个分区有一个leader，零或多个follower。Leader处理此分区的所有的读写请求而follower被动的复制数据。如果leader当机，其它的一个follower会被推举为新的leader。
一台服务器可能同时是一个分区的leader，另一个分区的follower。 这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理。
Kafka的保证(Guarantees)
- 生产者发送到一个特定的Topic的分区上的消息将会按照它们发送的顺序依次加入
- 消费者收到的消息也是此顺序
- 如果一个Topic配置了复制因子( replication facto)为N， 那么可以允许N-1服务器当掉而不丢失任何已经增加的消息
扩展性
kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在 zookeeper注册并保持相关的元数据（topic，partition信息等）更新。而客户端会在zookeeper上注册相关的watcher。 一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。
负载均衡
负载均衡可以分为两个部分：producer发消息的负载均衡和consumer读消息的负载均衡。
producer有一个到当前所有broker的连接池，当一个消息需要发送时，需要决定发到哪个broker（即partition）。这是由 partitioner实现的，partitioner是由应用程序实现的。应用程序可以实现任意的分区机制。要实现均衡的负载均衡同时考虑到消息顺序的 问题（只有一个partition/broker上的消息能保证按顺序投递），partitioner的实现并不容易。个人认为这一点还有待改进。
consumer读取消息时，除了考虑当前的broker情况外，还要考虑其他consumer的情况，才能决定从哪个partition读取消息。具体的机制还不是很清楚，需要做更深入的研究。
设计目标
（1）数据在磁盘上存取代价为O(1)。一般数据在磁盘上是使用BTree存储的，存取代价为O（lgn）。
（2）高吞吐率。即使在普通的节点上每秒钟也能处理成百上千的message。
（3）显式分布式，即所有的producer、broker和consumer都会有多个，均为分布式的。
（4）支持数据并行加载到Hadoop中。
KafKa部署结构
Broker:中间人、代理人
如上图所示，在典型的Kafka集群中, Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。
kafka是显式分布式架构，producer、broker（Kafka）和consumer都可以有多个。Kafka的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。几个基本概念：
（1）message（消息）是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。如果consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer。
（2）Kafka是显式分布式的，多个producer、consumer和broker可以运行在一个大的集群上，作为一个逻辑整体对外提供服 务。对于consumer，多个consumer可以组成一个group，这个message只能传输给某个group中的某一个consumer.
负载均衡和容错
Producer和broker之间没有负载均衡机制。
broker和consumer之间利用zookeeper进行负载均衡。所有broker和consumer都会在zookeeper中进行注册，且 zookeeper会保存他们的一些元数据信息。如果某个broker和consumer发生了变化，所有其他的broker和consumer都会得到通知。
用例 (Use CASE)
Kafka可以用于：
- 消息系统， 例如ActiveMQ 和 RabbitMQ.
- 站点的用户活动追踪。 用来记录用户的页面浏览，搜索，点击等。
- 操作审计。 用户/管理员的网站操作的监控。
- 日志聚合。收集数据，集中处理。
- 流处理。
部署步骤：
可参考官网文档：http://kafka.apache.org/documentation.html#quickstart
第一步: 下载代码并解压
http://kafka.apache.org/downloads.html
第二步: 修改配置并启动
Kafka使用Zookeeper所以你可能先要安装一个ZooKeeper.你可以使用kafka中打包好的脚本或者一个配置好的Zookeeper.
修改conf/server.properties
host.name=。。。。 （修改为主机ip,不然服务器返回给客户端的是主机的hostname,客户端并不一定能够识别）
broker.id=111 （唯一，非负整数）
listeners=PLAINTEXT://10.0.30.199:9092
我的配置如下：（各相关具体的设置含义见下文）
broker.id=111 listeners=PLAINTEXT://10.0.30.199:9092 num.network.threads=8 num.io.threads=8 socket.send.buffer.bytes=1048576 socket.receive.buffer.bytes=1048576 socket.request.max.bytes=104857600 log.dirs=/tmp/kafka-logs num.partitions=2 log.retention.hours=168 log.segment.bytes=536870912 log.retention.check.interval.ms=60000 log.cleaner.enable=false zookeeper.connect=172.16.65.25:2181,172.16.65.26:2181 zookeeper.connection.timeout.ms=1000000 delete.topic.enable=true
启动zookeeper和kafka：
> bin/zookeeper-server-start.sh config/zookeeper.properties （此处如果有单独布置过zookeeper可不用再次启动）
> bin/kafka-server-start.sh config/server.properties &
第三步: 新建一个话题Topic
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
注：此处--zookeeper 如果有多个的话，要全部列出，以逗号隔开。
查看已存在的Topic列表:
> bin/kafka-topics.sh --list --zookeeper localhost:2181 test
查看每个或所有topic的详细描述信息。第一行给出了分区的汇总信息。每个分区行给出分区信息
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic mytopic
Topic:mytopic PartitionCount:1 ReplicationFactor:3 Configs: Topic: mytopic Partition: 0 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
“leader” 节点名称是1,而不是代表的数量。
“replicas” 信息，分别在节点1,2,0上，不管node死活，只是列出信息而已.
“isr” 工作中的复制节点的集合. 也就是存活的节点的集合.
删除话题： 首先删除kafka存储目录（server.properties文件log.dirs配置，默认为"/tmp/kafka-logs"）
> rm -fr /tmp/kafka-logs/ttt222*
> bin/kafka-topics.sh --delete --zookeeper 172.16.65.25:2181,172.16.65.26:2181,172.16.65.27:2181 --topic ttt222
第四步: 发送消息
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
This is a message
This is another message
第五步: 消费消息
> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
This is a message
This is another messag
两个窗口的发送和消费消息相同则表示部署成功。
之后可以做进一步的实验，分别停掉flower和leader的broker,观察各主题的状态和消息的发送、消费情况。
在进行第四步和第五步时，有时会报如下错误：
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
解决办法：
下载slf4j安装包
http://www.slf4j.org/download.html
解压
unzip slf4j-1.7.6.zip
把slf4j-nop-1.7.6.jar 包复制到kafka libs目录下面
cd slf4j-1.7.6
cp slf4j-nop-1.7.6.jar /root/kafka/libs/
----------------------------------------------------------------------
broker.id 默认值：无
每一个broker都有一个唯一的id，这是一个非负整数，这个id就是broker的"名字"，这样就允许broker迁移到别的机器而不会影响消费者。你可以选择任意一个数字，只要它是唯一的。
log.dirs 默认值：/tmp/kafka-logs
一个用逗号分隔的目录列表，可以有多个，用来为Kafka存储数据。每当需要为一个新的partition分配一个目录时，会选择当前的存储partition最少的目录来存储。
port 默认值：9092
server用来接受client请求的端口。
zookeeper.connect 默认值：null
指定了ZooKeeper的connect string，以hostname:port的形式，hostname和port就是ZooKeeper集群各个节点的hostname和port。ZooKeeper集群中的某个节点可能会挂掉，所以可以指定多个节点的connect string。如下所式：
hostname1:port1,hostname2:port2,hostname3:port3 .
ZooKeeper也可以允许你指定一个"chroot"的路径，可以让Kafka集群将需要存储在ZooKeeper的数据存储到指定的路径下这可以让多个Kafka集群或其他应用程序公用同一个ZooKeeper集群。可以使用如下的connect string：
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path
这样就可以讲这个集群的所有数据存放在/chroot/path路径下。注意在启动集群前，一定要先自己创建这个路径，consumer也得使用相同的connect string。
message.max.bytes 默认值：1000000
server能接收的一条消息的最大的大小。这个属性跟consumer使用的最大fetch大小是一致的，这很重要，否则一个不守规矩的producer会发送一个太大的消息。
num.network.threads 默认值：3
处理网络的线程的数量，server端用来处理网络请求，一般不需要改变它。
num.io.threads 默认值：8
server端处理请求时的I/O线程的数量，不要小于磁盘的数量。
background.threads 默认值：4
用来处理各种不同的后台任务的线程数量，比如删除文件，一般不需要改变它。
queued.max.requests 默认值：500
I/O线程等待队列中的最大的请求数，超过这个数量，network线程就不会再接收一个新的请求。
host.name 默认值：null
broker的hostname，如果设置了它，会仅绑定这个地址。如果没有设置，则会绑定所有的网络接口，并提交一个给ZK。
advertised.host.name 默认值：null
如果设置了这个hostname，会分发给所有的producer，consumer和其他broker来连接自己。
advertised.port 默认值：null
分发这个端口给所有的producer，consumer和其他broker来建立连接。如果此端口跟server绑定的端口不同，则才有必要设置。
socket.send.buffer.bytes 默认值：100 * 1024
server端用来处理socket连接的SO_SNDBUFF缓冲大小。
socket.receive.buffer.bytes 默认值：100 * 1024
server端用来处理socket连接的SO_RCVBUFF缓冲大小。
socket.request.max.bytes 默认值：100 * 1024 * 1024
server能接受的请求的最大的大小，这是为了防止server跑光内存，不能大于Java堆的大小。
num.partitions 默认值：1
如果在创建topic的时候没有指定partition的数量，则使用这个值来设置。
log.segment.bytes 默认值：1024 * 1024 * 1024
一个topic的一个partition对应的所有segment文件称为log。这个设置控制着一个segment文件的最大的大小，如果超过了此大小，就会生成一个新的segment文件。此配置可以被覆盖，参考 the per-topic configuration section。
log.roll.hours 默认值：24 * 7
这个设置会强制Kafka去roll一个新的log segment文件，即使当前使用的segment文件的大小还没有超过log.segment.bytes。此配置可以被覆盖，参考 the per-topic configuration section。
log.cleanup.policy 默认值：delete
此配置可以设置成delete或compact。如果设置为delete，当log segment文件的大小达到上限，或者roll时间达到上限，文件将会被删除。如果设置成compact，则此文件会被清理，标记成已过时状态，详见 log compaction 。此配置可以被覆盖，参考 the per-topic configuration section。
log.retention.minutes 默认值：7 days
在删除log文件之前，保存在磁盘的时间，单位为分钟，这是所有topic的默认值。注意如果同时设置了log.retention.minutes和log.retention.bytes，如果达到任意一个条件的限制，都会马上删掉。此配置可以被覆盖，参考 the per-topic configuration section。
log.retention.bytes 默认值：-1
topic每个分区的最大文件大小，一个topic的大小限制 = 分区数 * log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除。此配置可以被覆盖，参考 the per-topic configuration section。
log.retention.check.interval.ms 默认值：5 minutes
检查任意一个log segment文件是否需要进行retention处理的时间间隔。
log.cleaner.enable 默认值：false
设置为true就开启了log compaction功能。
log.cleaner.threads 默认值：1
使用log compaction功能来清理log的线程的数量。
log.cleaner.io.max.bytes.per.second 默认值：None
在执行log compaction的过程中，限制了cleaner每秒钟I/O的数据量，以免cleaner影响正在执行的请求。
log.cleaner.dedupe.buffer.size 默认值：500 * 1024 * 1024
日志压缩去重时候的缓存空间，在空间允许的情况下，越大越好。
log.cleaner.io.buffer.size 默认值：512 * 1024
日志清理时候用到的I/O块(chunk)大小，一般不需要修改。
log.cleaner.io.buffer.load.factor 默认值：0.9
日志清理中hash表的扩大因子，一般不需要修改。
log.cleaner.backoff.ms 默认值：15000
检查log是否需要clean的时间间隔。
log.cleaner.min.cleanable.ratio 默认值：0.5
控制了log compactor进行clean操作的频率。默认情况下，当log的50%以上已被clean时，就不用继续clean了。此配置可以被覆盖，参考 the per-topic configuration section。
log.cleaner.delete.retention.ms 默认值：1 day
对于压缩的日志保留的最长时间，也是客户端消费消息的最长时间，同log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据，参考 the per-topic configuration section。
log.index.size.max.bytes 默认值：10 * 1024 * 1024
每一个log segment文件的offset index文件的最大的size。注意总是预分配一个稀疏(sparse)文件，当roll这个文件时再shrink down。如果index文件被写满，那么就roll一个新的log segment文件，即使还没达到log.segment.byte限制。参考 the per-topic configuration section。
log.index.interval.bytes 默认值：4096
当执行一个fetch操作后，需要一定的空间来扫描最近的offset大小，设置越大，代表扫描速度越快，但是也更耗内存，一般情况下不需要改变这个参数。
log.flush.interval.messages 默认值：None
在强制fsync一个partition的log文件之前暂存的消息数量。调低这个值会更频繁的sync数据到磁盘，影响性能。通常建议人家使用replication来确保持久性，而不是依靠单机上的fsync，但是这可以带来更多的可靠性。
log.flush.scheduler.interval.ms 默认值：3000
log flusher检查是否需要把log刷到磁盘的时间间隔，单位为ms。
log.flush.interval.ms 默认值：None
2次fsync调用之间最大的时间间隔，单位为ms。即使log.flush.interval.messages没有达到，只要这个时间到了也需要调用fsync。
log.delete.delay.ms 默认值：60000
在log文件被移出索引后，log文件的保留时间。在这段时间内运行的任意正在进行的读操作完成操作，不用去打断它。通常不需要改变。
log.flush.offset.checkpoint.interval.ms 默认值：60000
记录上次把log刷到磁盘的时间点的频率，用来日后的recovery。通常不需要改变。
auto.create.topics.enable 默认值：true
是否允许自动创建topic。如果设为true，那么produce，consume或者fetch metadata一个不存在的topic时，就会自动创建一个默认replication factor和partition number的topic。
controller.socket.timeout.ms 默认值：30000
partition管理控制器发向replica的命令的socket超时时间。
controller.message.queue.size 默认值：10
partition leader与replicas数据同步时的消息的队列大小。
default.replication.factor 默认值：1
自动创建topic时的默认replication factor的个数。
replica.lag.time.max.ms 默认值：10000
如果一个follower在有一个时间窗口内没有发送任意fetch请求，leader就会把这个follower从ISR(in-sync replicas)移除，并认为它已挂掉。
replica.lag.max.messages 默认值：4000
如果一个replica落后leader此配置指定的消息条数，leader就会把它移除ISR，并认为它挂掉。
replica.socket.timeout.ms 默认值：300 * 1000
复制数据过程中，replica发送给leader的网络请求的socket超时时间。
replica.socket.receive.buffer.bytes 默认值：64 * 1024
复制数据过程中，replica发送网络请求给leader的socket receiver buffer的大小。
replica.fetch.max.bytes 默认值：1024 * 1024
复制数据过程中，replica发送给leader的fetch请求试图获取数据的最大的字节数。
replica.fetch.wait.max.ms 默认值：500
复制数据过程中，为了fetch数据，replica发送请求给leader的最大的等待时间。
replica.fetch.min.bytes 默认值：1
复制数据过程中，replica收到的每个fetch响应，期望的最小的字节数，如果没有收到足够的字节数，就会等待期望更多的数据，直到达到replica.fetch.wait.max.ms。
num.replica.fetchers 默认值：1
用来从leader复制消息的线程数量，增大这个值可以增加follow的I/O并行度。
replica.high.watermark.checkpoint.interval.ms 默认值：5000
每一个replica存储自己的high watermark到磁盘的频率，用来日后的recovery。
fetch.purgatory.purge.interval.requests 默认值：10000
含义暂不明，日后研究。The purge interval (in number of requests) of the fetch request purgatory.
producer.purgatory.purge.interval.requests 默认值：10000
含义暂不明，日后研究。The purge interval (in number of requests) of the producer request purgatory.
zookeeper.session.timeout.ms 默认值：6000
ZooKeeper的session的超时时间，如果在这段时间内没有收到ZK的心跳，则会被认为该Kafka server挂掉了。如果把这个值设置得过低可能被误认为挂掉，如果设置得过高，如果真的挂了，则需要很长时间才能被server得知。
zookeeper.connection.timeout.ms 默认值：6000
client连接到ZK server的超时时间。
zookeeper.sync.time.ms 默认值：2000
一个ZK follower能落后leader多久。
controlled.shutdown.enable 默认值：false
如果为true，在关闭一个broker前，会把当前broker上的所有partition，如果有为leader的话，会把leader权交给其他broker上的相应的partition。这会降低在关闭期间不可用的时间窗口。
controlled.shutdown.max.retries 默认值：3
在执行一个unclean(强行关闭？)的关闭操作前，为了成功完成关闭操作，最大的重试次数。
controlled.shutdown.retry.backoff.ms 默认值：5000
在关闭重试期间的回退(backoff)时间。
auto.leader.rebalance.enable 默认值：false
如果设为true，复制控制器会周期性的自动尝试，为所有的broker的每个partition平衡leadership，为更优先(preferred)的replica分配leadership。
leader.imbalance.per.broker.percentage 默认值：10
每个broker允许的不平衡的leader的百分比。如果每个broker超过了这个百分比，复制控制器会重新平衡leadership。
leader.imbalance.check.interval.seconds 默认值：300
检测leader不平衡的时间间隔。
offset.metadata.max.bytes 默认值：1024
允许client(消费者)保存它们元数据(offset)的最大的数据量。