Kafka_004：对比其它消息中间件 （摘录+整理）

1. 测试环境
LinkedIn团队做了个实验研究，对比Kafka与Apache ActiveMQ V5.4和RabbitMQ V2.4的性能。他们使用ActiveMQ默认的消息持久化库Kahadb。LinkedIn在两台Linux机器上运行他们的实验，每台机器的配置为8核2GHz、16GB内存，6个磁盘使用RAID10。两台机器通过1GB网络连接。一台机器作为代理，另一台作为生产者或者消费者。

2. 生产者测试
LinkedIn团队在所有系统中配置代理，异步将消息刷入其持久化库。对每个系统，运行一个生产者，总共发布1000万条消息，每条消息200字节。Kafka生产者以1和50批量方式发送消息。ActiveMQ和RabbitMQ似乎没有简单的办法来批量发送消息，LinkedIn假定它的批量值为1。结果如下图所示：

 Kafka 性能要好很多的主要原因包括：
（1）Kafka不等待代理的确认，以代理能处理的最快速度发送消息。
（2）Kafka有更高效的存储格式。平均而言，Kafka每条消息有9字节的开销，而ActiveMQ有144字节。其原因是JMS所需的沉重消息头，以及维护各种索引结构的开销。LinkedIn注意到ActiveMQ一个最忙的线程大部分时间都在存取B-Tree以维护消息元数据和状态。

3. 消费者测试
为了做消费者测试，LinkedIn使用一个消费者获取总共1000万条消息。LinkedIn让所有系统每次拉请求都预获取大约相同数量的数据，最多1000条消息或者200KB。对ActiveMQ和RabbitMQ，LinkedIn设置消费者确认模型为自动。结果如下图所示：

Kafka性能要好很多的主要原因包括：
（1）Kafka有更高效的存储格式；在Kafka中，从代理传输到消费者的字节更少。
（2）ActiveMQ和RabbitMQ两个容器中的代理必须维护每个消息的传输状态。LinkedIn团队注意到其中一个ActiveMQ线程在测试过程中，一直在将KahaDB页写入磁盘。与此相反，Kafka代理没有磁盘写入动作。最后，Kafka通过使用sendfile API降低了传输开销。

Kafka_003：各个组件介绍（摘录+整理）

1. Topics
Kafka 只支持基于 Topic 的发布/订阅模式，它并没有实现 JMS 规范。

一个 Topic 可以认为是一类消息，每个 Topic 被分成多个 partitions，每个 partition 是一个有序的队列，在物理存储层面，每个 partition 由多个日志文件组成。每条发布到 partition 的消息都会以 append 方式写到日志文件的尾部，每条消息在文件中的位置称为 offset，offset 是一个 long 型数字，它唯一的标记一条消息。

2. Broker
Broker 不维护 Producer 和 Consumer 的状态信息，这些信息由 Zookeeper 保存，即 Broker 本身是无状态的。

一个 Topic 的多个 partitions 被分布在 Kafka 集群中的多个 Broker 上，每个 Broker 负责 partitions 中消息的读写操作。

此外，Kafka 还可以配置 partitions 的副本个数（replicas），将 partition 备份到多台机器上，提高可用性。

基于 partitions 的副本方案，意味着需要对多个备份进行调度，每个 partition 都有一个 leader 负责所有的读写操作，如果 leader 失效，那么会有一个 follower成为新的 leader 来接管工作。follower 本身不接受用户请求，只是和 leader 进行消息同步。

有多少个 partitions 就有多少个 leader，Kafka 会把 leader 均衡地分布在每个 Broker 实例上，来确保整体的性能稳定。

3. Producers 生产者

Producer 将消息发布到指定的 Topic 中，同时 Producer 也能决定消息归属于哪个 partition，比如基于 round-robin 方式或者通过其他的一些算法等。

4. Consumers 消费者

每个 Consumer 属于一个 Consumer Group；一个 Consumer Group 可以有多个 Consumers。

发送到 Topic 的消息，只会被订阅此 Topic 的每个 Consumer Group 中的一个 Consumer 消费，因此可以认为一个 Consumer Group 是一个“订阅者”。

如果所有的 Consumer 都具有相同的 Consumer Group，消息将会在所有的 Consumers 之间负载均衡，跟 Queue 特性很像。

如果所有的 Consumer 都具有不相同的 Consumer Group，消息将会广播给所有的 Consumers，跟 Topic 特性一样。

Consumer 需要保存已消费消息的 offset。

再说的仔细些，一个 Topic 中的每个 partition，只会被一个“订阅者”（一个 Consumer Group）中的一个 Consumer 消费；不过，一个 Consumer 可以消费多个 partitions 中的消息。

Kafka 的设计原理决定：对于一个 Topic，同一个 Consumer Group 中不能有多于 partitions 个数的 Consumer 同时消费，否则意味着某些 Consumer 将无法得到消息。

Kafka只能保证一个 partition 中的消息被某个 Consumer 消费时是按顺序消费的。但从 Topic 角度来说，消息仍然不是有序消费的.

Kafka 保证

（1）发送到 partitions 中的消息将会按照它接收的顺序追加到日志中。

（2）对于 Consumer 而言，它们消费消息的顺序和日志中消息顺序一致。

（3）如果 Topic 的 replicationfactor=N，那么允许 N-1 个 broker 实例失效。

5. 存储

Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上，一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正写入磁盘中。写入完成后，消息公开给消费者。

与传统的消息系统不同，Kafka系统中存储的消息没有明确的消息Id。

消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套密集寻址，用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量的，但不连续。要计算下一消息的ID，可以在其逻辑偏移的基础上加上当前消息的长度。

消费者始终从特定分区顺序地获取消息，如果消费者知道特定消息的偏移量，也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求，准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量。Kafka利用sendfile API高效地从代理的日志段文件中分发字节给消费者。

参考文献：
1. http://www.infoq.com/cn/articles/apache-kafka/
2. http://www.cnblogs.com/likehua/p/3999538.html

Kafka_002：快速上手

环境：MAC OS X EI Capitan 10.11.2 + Kafka 0.9.0

1. 下载
地址：https://kafka.apache.org/downloads.html
介质：kafka_2.11-0.9.0.0.tgz

2. 安装
（1）tar zxvf kafka_2.11-0.9.0.0.tgz
（2）ln -s kafka_2.11-0.9.0.0 kafka

3. 启动一个单节点的 zookeeper
（1）cd kafka
（2）bin/zookeeper-server-start.sh config/zookeeper.properties
         或 nohup bin/zookeeper-server-start.sh config/zookeeper.properties &

4. 启动一个单节点的kafka server (即 broker)
（1）cd kafka
（2）bin/kafka-server-start.sh config/server.properties
（3）创建 Topic
   $ bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
   Created topic "test".
（4）查看 Topic
   $ bin/kafka-topics.sh --list --zookeeper localhost:2181
   test
（5）启动 Producer，并发送消息
   $ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
   This is a message
   This is another message
（6）启动 Consumer，等待接收消息
   $ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning
   This is a message
   This is another message

5. 启动3个kafka server，组成 broker 集群
（1）cd kafka
（2）创建并修改server-1配置文件
   $ cp config/server.properties config/server-1.properties
   $ vim config/server-1.properties       
    broker.id=1
    listeners=PLAINTEXT://:9093
    port=9093
    log.dir=/tmp/kafka-logs-1
（3）创建并修改server-2配置文件
   $ cp config/server.properties config/server-2.properties
   $ vim config/server-2.properties       
    broker.id=2
    listeners=PLAINTEXT://:9094
    port=9094
    log.dir=/tmp/kafka-logs-2
（4）启动 kafka server-1 和 kafka server-2
    $ bin/kafka-server-start.sh config/server-1.properties &
    $ bin/kafka-server-start.sh config/server-2.properties &
   加上之前已经启动的 server，这样一共是3个kafka server，组成一个集群。
（5）创建一个新的 Topic，带 replication-factor 参数
    $ bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
（6）查看 Topic：my-replicated-topic
    $ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
   Topic:my-replicated-topic    PartitionCount:1    ReplicationFactor:3    Configs:
   Topic:my-replicated-topic    Partition: 0    Leader: 2    Replicas: 2,1,0    Isr: 0,1,2
   说明：
   partiton： partion id，由于此处只有一个partition，因此 partition id 为 0。
   leader：当前负责读写的lead broker id。
   relicas：当前 partition 的所有replication broker  list。
   isr：relicas 的子集，只包含出于活动状态的broker。
（7）查看 Topic：test
    $ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
   Topic:test    PartitionCount:1    ReplicationFactor:1    Configs:
   Topic:test    Partition: 0    Leader: 0    Replicas: 0    Isr: 0
（8）发布消息到新的 Topic
    $ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
   my test message 1
   my test message 2
（9）消费消息
    $ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
（10）测试容错：fault-tolerance
    $ ps | grep server-1.properties
    $ kill -9 34650
    $ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
  Topic:my-replicated-topic    PartitionCount:1    ReplicationFactor:3    Configs:
  Topic:my-replicated-topic    Partition: 0    Leader: 2    Replicas: 2,1,0    Isr: 0,2
 继续发送消息，消息接收正常。
    $ ps | grep server-2.properties
    $ kill -9 34653
    $ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
   Topic:my-replicated-topic    PartitionCount:1    ReplicationFactor:3    Configs:
   Topic:my-replicated-topic    Partition: 0    Leader: 0    Replicas: 2,1,0    Isr: 0
 继续发送消息，消息接收正常。

参考文献：
1. http://blog.csdn.net/yfkiss/article/details/17381351
2. https://kafka.apache.org

Kafka_001：基本特点与原理 （摘录+整理）

Kafka 是 LinkedIn 开发并开源出来的一个高吞吐的分布式消息系统。特点如下：

• 高吞吐量
  在标准硬件之上，支持每秒数百万的消息。
• 横向扩展
  不停机扩展机器节点。
• 数据持久化
  保证消息不丢失，时间复杂度为O(1)的磁盘结构，提供了常量时间的性能，即使是海量信息（TB级）。
• 实时
  生产者产生的消息对消费者立即可见，对基于事件的系统（比如CEP）是至关重要的。
• 多客户端支持
  客户端支持：java、.NET、PHP、Ruby、Python。
• 分布式
  支持消息分区，以及在消费机器集群上的分发消息，并维护每个分区的排序语义。

1. 适用与不适用场景
（1）Kafka 不能保证消息的发送与接收绝对可靠性，因此不适用于对消息可靠性要求很高的消息系统。
（2）用户行为数据
跟踪网页活动（Websit Activity Tracking）的最佳工具；可以将网页/用户操作等信息发送到 Kafka 中，并实时监控或离线分析。
（3）Kafka 适合收集日志，应用可以把操作日志批量、异步地发送到 Kafka 集群中，这对 Producer 端而言，几乎感觉不到性能的开支，而且 Consumer 端可以使用 Hadoop 等其他系统化的存储和分析系统。
（4）基于事件的消息

2.  架构图

多个broker协同合作，producer和consumer部署在各个业务逻辑中被频繁的调用，三者通过zookeeper管理协调请求和转发。
producer到broker的过程是push，也就是有数据就推送到broker，而consumer到broker的过程是pull，是通过consumer主动去拉数据的，而不是broker把数据主动发送到consumer端的。
启动顺序如下：
（1）启动 zookeeper 的 server，即图中的ZooKeeper。
（2）启动 kafka 的 server，即图中的Broker。
（3）启动 Producer，如果生产了数据，会先通过 ZooKeeper找到Broker，然后将数据存放进Broker。
（4）启动 Consumer，如果要消费数据，会先通过ZooKeeper找到对应的Broker，然后消费。

ZooKeeper 用于管理、协调 Broker。每个 Broker 都通过 ZooKeeper 协调其它 Broker。当 Kafka系统中新增了代理或者某个代理故障失效时，ZooKeeper 服务将通知生产者和消费者。生产者和消费者据此开始与其它 Broker 协调工作。

3. 小结
Kafka提供了一个实时的发布/订阅解决方案，它克服了消费实时大数据的挑战。Kafka还支持在Hadoop系统上做并行数据载入。

参考文献：
1. http://blog.csdn.net/yfkiss/article/details/17348693
2. http://blog.csdn.net/chszs/article/details/20875793
3. http://m.open-open.com/m/lib/view/1354277579741.html