共计 7573 个字符，预计需要花费 19 分钟才能阅读完成。
Kafka 是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。也可以把它当作是分布式提交日志的发布 - 订阅消息，事实上 Kafka 官网上也是这么说明的。
关于 Kafk 你必须知道的几个关键术语
topics：Kafka 接收的各种各样的消息
producers：发送消息到 Kafka
consumers：从 Kafka 接收消息的订阅者
broker：一个或多个服务器组成的 Kakfa 集群
下图是一个生产者通过 kafka 集群发送给消费者的示例
Topics 和 Logs
一个 Topic 就是将发布的消息归类的过程，对于每一个 topic，Kafka 集群都会维护一个分区日志，如下图
每个分区都是有编号的，而且每个分区的消息也会根据提交的日志进行编号。分区中的消息会被分配一个唯一的编号，这个术语叫做 offset，用以识别分区中的消息。
Kafka 集群会保存所有的发布消息，无论这些消息在固定的时间内是否被消费者所消费。比如，消息日志设置的保存期间是 2 天，在消息发布的 2 天内，消费者可以消费，然后丢弃该条消息来释放空间。Kafka 的性能跟数据空间无关，因此保存大量数据对于 Kafka 来说不是问题。
实际上，在日志中保存每个消费者位置的元数据才是“offset”。offset 是由消费者控制的：一般来说，当消费者一行行读取消息时，offset 才起作用。但实际上，消费者可以以任意他们想要的方式读取消息，因为消费者可以重置已存在的 offset。
这种机制表明 Kafka 消费者是非常容易处理的 - 消息的处理对于集群或其它消费者来说几乎没有什么影响。比如，我们可以在命令行工具中使用“tail”topic 来处理消息而不用改变已经存在的消费者。
日志分区有几种不同的目的。首先，能够避免一台服务器上的日志文件过大。每个独立的分区肯定位于同一台服务器上，并且在同一台服务器上处理，但是一个 topic 可能有多个分区，这样能够保证处理大量的数据。其次， 分区可以作为并行处理的单元。
分布式
日志分布在 Kafka 集群中的不同分区上，每个服务器处理数据并请求共享分区。每个分区都是可以通过配置服务器的容错机制进行复制的。
每个分区都有一个服务器作为“leader（主节点）”，有 0 个或多个服务器作为“followers（从节点）”，主节点可以从分区中读写数据，但是从节点只能复制主节点的消息。如果主节点宕机，其中的一个从服务器会自动成为新的主服务器。主服务器处理一些分区的数据，从服务器处理其它服务器的数据，这样保存集群的平衡。
生产者（Producers）
生产者可以决定将消息发送到哪些 topic，而且生产者可以选择将 topic 内的消息发送到哪个分区。这种简单的循环负载均衡方式能够在语义分区时完成。这种分区通常在 1 秒内完成。
消费者（Consumers）
传统的消息队列有两种处理方式：顺序处理和发布 / 订阅处理。在顺序处理方式时，消费者是按照消息进入消息队列的顺序进行读取的。发布 / 订阅方式则是将消息广播给所有的消费者。Kafka 提供了一种抽象的方式 - 消费者分组（consumer group）来满足消息的以上两种处理方式。
每个消费者都有一个组名，只有订阅的消费者在对应的组中时，发布到 topic 中的消息才会传递给消费者对象。消费者对象可以在不同的进程或主机中存在。
如果所有的消费者对象的组名都相同，这就好比是传统的顺序队列，消费者平均分配这些消息。
如果所有的消费者对象的组名都不相同，这就好比是发布 / 订阅模式，消费者只接受订阅的消息。
通常来说，订阅某一主题（topic）的消费者在同一组的有多个，这是为了系统的稳定和容错。下图是一个具体的示例。
Kafka 比传统的消息队列拥有更高的排序可靠性。
传统的消息队列在顺序保存消息到服务器时，如果有多个消费者从队列中读取消息，服务器会顺序发送消息。但是，尽管服务器是顺序发送消息的，但是消费者是异步接收消息的，因此消费者接收到的消息可能并不是顺序的，但消费者并不知道消息是乱序的。为避免这种情况，传统的消息队列通常只允许一个进程读取消息，这也就意味着消息的处理是单向的，而不是并行的。
Kafka 在这方面有更好的处理方式，它通过在主题中使用分区完成了并行处理。Kafka 既保证了顺序输出又实现了消费者之间的平衡。通过给主题分配分区，将消息分给同组内的消费者，确保每一分区内的消费者是唯一的，并且是顺序读取消息。由于是通过分区来实现多个消费者对象的负载均衡，所以同一消费者组的消费者是不能超过分区的。
Kafka 仅仅实现了消息在一个分区内的排序，而不是同一主题不同分区内的排序。对于大多数应用而言，数据分区和分区内数据排序就足够了。如果你想要所有的消息都是顺序排列的，那就只能有一个分区，这意味着只能有一个消费者在一个消费者组内。这种情况下，消息的处理就不是并行的。
可靠性
消息会以生产者发送的顺序追加到主题的分区。例如，一个生产者发送同一个消息两次分别称为 M1，M2，M1 先发，那么 M1 将会有一个更小的偏移量，并且也会比 M2 早出现在日志中。
消费者以存储在日志中的顺序看见消息。
对于复制 N 倍的主题，即便 N - 1 台服务器出错，都不会使已经提交到日志的消息丢失
使用场景
消息代理
Kafka 可以替代一些传统的消息代理。消息代理有很多使用场景，比如与数据处理程序解耦，缓存未处理的消息等等。和大多数消息处理系统相比，Kafka 有更好的吞吐量，内建的分区，复制和容错能力，这使得 Kafka 能够很好的处理大规模消息应用。
活动追踪
Kafka 最初用来提供实时追踪网站用户行为的相关数据的能力，例如统计 PV,UV 等。
监控统计
Kafka 经常被用来操作监控数据，比如从分布式的应用中汇总统计数据。
日志收集
我们的服务通常部署在多台计算机上，服务器的运行日志也会分散打在各个机器上。Kafka 通常被用来从各个服务器上收集日志，然后统一打到 HDFS 或者其他离线存储系统，比如 Facebook 的 Scribe 在收集日志时就是用了 Kafka。
流处理
很多用户完成原始数据的阶段性汇总，加工等处理后，将操作结果转换为新的 topic 写入 Kafka 来进行更深入的处理。比如，文章推荐程序完首先是用爬虫从 RSS 中爬取用户订阅的文本内容，然后把这些内容发布到 articles topic 下。接下来的处理程序，将 articles topic 下的内容格式化后，发布到 format topic 下。最终的处理程序尝试将这些格式化的内容推荐给合适的用户。Storm 和 Samze 是处理这种业务的流行框架。
事件采集
业务状态的变化被按照时间顺序记录下来，这种程序设计方式被成为事件采集。Kafka 支持大规模的日志数据存储，这使得 Kafka 成为事件采集程序理想的后端模块。
更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2016-04/130018p2.htm
相关阅读 ：
分布式发布订阅消息系统 Kafka 架构设计 http://www.linuxidc.com/Linux/2013-11/92751.htm
Apache Kafka 代码实例 http://www.linuxidc.com/Linux/2013-11/92754.htm
Apache Kafka 教程笔记 http://www.linuxidc.com/Linux/2014-01/94682.htm
Apache kafka 原理与特性 (0.8V) http://www.linuxidc.com/Linux/2014-09/107388.htm
Kafka 部署与代码实例 http://www.linuxidc.com/Linux/2014-09/107387.htm
Kafka 介绍和集群环境搭建 http://www.linuxidc.com/Linux/2014-09/107382.htm
1. 从 Kafka 官网下载最新的 Kafka，目前最新版本为 0.9.0.1
2. 下载完毕后，上传到 Linux 服务器，并解压
tar -xzf kafka_2.11-0.9.0.1.tgz
3. 修改 Zookeeper 服务器配置，并启动
cd kafka_2.11-0.9.0.1
vi config/zookeeper.properties
# 修改 ZooKeeper 的数据目录
dataDir=/opt/favccxx/db/zookeeper
# 配置 host.name 和 advertised.host.name 为 IP 地址，防止通过 Java 客户端连接时解析为 localhost
host.name=10.0.10.6
advertised.host.name=10.0.10.6
# 启动 Zookeeper 服务器
./zookeeper-server-start.sh /opt/favccxx/kafka_2.11-0.9.0.1/config/zookeeper.properties
4. 修改 Kafka 配置，并启动 Kafka 服务器
vi config/server.properties
log.dirs=/opt/favccxx/kafka/kafka-logs
# 启动 Kafka 服务器
./kafka-server-start.sh /opt/favccxx/kafka_2.11-0.9.0.1/config/server.properties
5. 创建并查看 Topic
cd /opt/favccxx/kafka_2.11-0.9.0.1/bin/
./kafka-topics.sh –create –zookeeper localhost:2181 –replication-factor 1 –partitions 1 –topic test
Created topic “test”.
# 查看刚才的 topic
./kafka-topics.sh –list –zookeeper localhost:2181
test
6. 使用生产者发送消息，每行是一条独立的消息
./kafka-console-producer.sh –broker-list localhost:9092 –topic test
This is a message
This is My mesage
7. 使用消费者接收消息
./kafka-console-consumer.sh –zookeeper localhost:2181 –topic test –from-beginning
This is a message
This is My me
Kafka 的详细介绍 ：请点这里
Kafka 的下载地址 ：请点这里
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-04/130018.htm
Kafka 是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。也可以把它当作是分布式提交日志的发布 - 订阅消息，事实上 Kafka 官网上也是这么说明的。
关于 Kafk 你必须知道的几个关键术语
topics：Kafka 接收的各种各样的消息
producers：发送消息到 Kafka
consumers：从 Kafka 接收消息的订阅者
broker：一个或多个服务器组成的 Kakfa 集群
下图是一个生产者通过 kafka 集群发送给消费者的示例
Topics 和 Logs
一个 Topic 就是将发布的消息归类的过程，对于每一个 topic，Kafka 集群都会维护一个分区日志，如下图
每个分区都是有编号的，而且每个分区的消息也会根据提交的日志进行编号。分区中的消息会被分配一个唯一的编号，这个术语叫做 offset，用以识别分区中的消息。
Kafka 集群会保存所有的发布消息，无论这些消息在固定的时间内是否被消费者所消费。比如，消息日志设置的保存期间是 2 天，在消息发布的 2 天内，消费者可以消费，然后丢弃该条消息来释放空间。Kafka 的性能跟数据空间无关，因此保存大量数据对于 Kafka 来说不是问题。
实际上，在日志中保存每个消费者位置的元数据才是“offset”。offset 是由消费者控制的：一般来说，当消费者一行行读取消息时，offset 才起作用。但实际上，消费者可以以任意他们想要的方式读取消息，因为消费者可以重置已存在的 offset。
这种机制表明 Kafka 消费者是非常容易处理的 - 消息的处理对于集群或其它消费者来说几乎没有什么影响。比如，我们可以在命令行工具中使用“tail”topic 来处理消息而不用改变已经存在的消费者。
日志分区有几种不同的目的。首先，能够避免一台服务器上的日志文件过大。每个独立的分区肯定位于同一台服务器上，并且在同一台服务器上处理，但是一个 topic 可能有多个分区，这样能够保证处理大量的数据。其次， 分区可以作为并行处理的单元。
分布式
日志分布在 Kafka 集群中的不同分区上，每个服务器处理数据并请求共享分区。每个分区都是可以通过配置服务器的容错机制进行复制的。
每个分区都有一个服务器作为“leader（主节点）”，有 0 个或多个服务器作为“followers（从节点）”，主节点可以从分区中读写数据，但是从节点只能复制主节点的消息。如果主节点宕机，其中的一个从服务器会自动成为新的主服务器。主服务器处理一些分区的数据，从服务器处理其它服务器的数据，这样保存集群的平衡。
生产者（Producers）
生产者可以决定将消息发送到哪些 topic，而且生产者可以选择将 topic 内的消息发送到哪个分区。这种简单的循环负载均衡方式能够在语义分区时完成。这种分区通常在 1 秒内完成。
消费者（Consumers）
传统的消息队列有两种处理方式：顺序处理和发布 / 订阅处理。在顺序处理方式时，消费者是按照消息进入消息队列的顺序进行读取的。发布 / 订阅方式则是将消息广播给所有的消费者。Kafka 提供了一种抽象的方式 - 消费者分组（consumer group）来满足消息的以上两种处理方式。
每个消费者都有一个组名，只有订阅的消费者在对应的组中时，发布到 topic 中的消息才会传递给消费者对象。消费者对象可以在不同的进程或主机中存在。
如果所有的消费者对象的组名都相同，这就好比是传统的顺序队列，消费者平均分配这些消息。
如果所有的消费者对象的组名都不相同，这就好比是发布 / 订阅模式，消费者只接受订阅的消息。
通常来说，订阅某一主题（topic）的消费者在同一组的有多个，这是为了系统的稳定和容错。下图是一个具体的示例。
Kafka 比传统的消息队列拥有更高的排序可靠性。
传统的消息队列在顺序保存消息到服务器时，如果有多个消费者从队列中读取消息，服务器会顺序发送消息。但是，尽管服务器是顺序发送消息的，但是消费者是异步接收消息的，因此消费者接收到的消息可能并不是顺序的，但消费者并不知道消息是乱序的。为避免这种情况，传统的消息队列通常只允许一个进程读取消息，这也就意味着消息的处理是单向的，而不是并行的。
Kafka 在这方面有更好的处理方式，它通过在主题中使用分区完成了并行处理。Kafka 既保证了顺序输出又实现了消费者之间的平衡。通过给主题分配分区，将消息分给同组内的消费者，确保每一分区内的消费者是唯一的，并且是顺序读取消息。由于是通过分区来实现多个消费者对象的负载均衡，所以同一消费者组的消费者是不能超过分区的。
Kafka 仅仅实现了消息在一个分区内的排序，而不是同一主题不同分区内的排序。对于大多数应用而言，数据分区和分区内数据排序就足够了。如果你想要所有的消息都是顺序排列的，那就只能有一个分区，这意味着只能有一个消费者在一个消费者组内。这种情况下，消息的处理就不是并行的。
可靠性
消息会以生产者发送的顺序追加到主题的分区。例如，一个生产者发送同一个消息两次分别称为 M1，M2，M1 先发，那么 M1 将会有一个更小的偏移量，并且也会比 M2 早出现在日志中。
消费者以存储在日志中的顺序看见消息。
对于复制 N 倍的主题，即便 N - 1 台服务器出错，都不会使已经提交到日志的消息丢失
使用场景
消息代理
Kafka 可以替代一些传统的消息代理。消息代理有很多使用场景，比如与数据处理程序解耦，缓存未处理的消息等等。和大多数消息处理系统相比，Kafka 有更好的吞吐量，内建的分区，复制和容错能力，这使得 Kafka 能够很好的处理大规模消息应用。
活动追踪
Kafka 最初用来提供实时追踪网站用户行为的相关数据的能力，例如统计 PV,UV 等。
监控统计
Kafka 经常被用来操作监控数据，比如从分布式的应用中汇总统计数据。
日志收集
我们的服务通常部署在多台计算机上，服务器的运行日志也会分散打在各个机器上。Kafka 通常被用来从各个服务器上收集日志，然后统一打到 HDFS 或者其他离线存储系统，比如 Facebook 的 Scribe 在收集日志时就是用了 Kafka。
流处理
很多用户完成原始数据的阶段性汇总，加工等处理后，将操作结果转换为新的 topic 写入 Kafka 来进行更深入的处理。比如，文章推荐程序完首先是用爬虫从 RSS 中爬取用户订阅的文本内容，然后把这些内容发布到 articles topic 下。接下来的处理程序，将 articles topic 下的内容格式化后，发布到 format topic 下。最终的处理程序尝试将这些格式化的内容推荐给合适的用户。Storm 和 Samze 是处理这种业务的流行框架。
事件采集
业务状态的变化被按照时间顺序记录下来，这种程序设计方式被成为事件采集。Kafka 支持大规模的日志数据存储，这使得 Kafka 成为事件采集程序理想的后端模块。
更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2016-04/130018p2.htm
相关阅读 ：
分布式发布订阅消息系统 Kafka 架构设计 http://www.linuxidc.com/Linux/2013-11/92751.htm
Apache Kafka 代码实例 http://www.linuxidc.com/Linux/2013-11/92754.htm
Apache Kafka 教程笔记 http://www.linuxidc.com/Linux/2014-01/94682.htm
Apache kafka 原理与特性 (0.8V) http://www.linuxidc.com/Linux/2014-09/107388.htm
Kafka 部署与代码实例 http://www.linuxidc.com/Linux/2014-09/107387.htm
Kafka 介绍和集群环境搭建 http://www.linuxidc.com/Linux/2014-09/107382.htm
