Kafka 开发架构的一些问题汇总
一、Kafka 存在哪些方面的优势
1. 多生产者
可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。
2. 多消费者
支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。
3. 基于磁盘的数据存储
支持消费者非实时地读取消息，由于消息被提交到磁盘，根据设置的规则进行保存。当消费者发生异常时候，意外离线，由于有持久化的数据保证，可以实现联机后从上次中断的地方继续处理消息。
4. 伸缩性
用户在开发阶段可以先试用单个 broker，再扩展到包含 3 个 broker 的小型开发集群，然后随着数据量不断增长，部署到生产环境的集群可能包含上百个 broker。
5. 高性能
Kafka 可以轻松处理巨大的消息流，在处理大量数据的同事，它还能保证亚秒级的消息延迟。
二、Kafka 常见的使用场景
1. 消息
kafka 更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息等），与大多数消息系统比较，kafka 有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息。
根据我们的经验，消息往往用于较低的吞吐量，但需要低的端到端延迟，并需要提供强大的耐用性的保证。
在这一领域的 kafka 比得上传统的消息系统，如 ActiveMQ 或 RabbitMQ 等。
2. 网站活动追踪
kafka 原本的使用场景是用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理，实时监测，也可加载到 Hadoop 或离线处理数据仓库。
3. 指标
kafka 也常常用于监测数据。分布式应用程序生成的统计数据集中聚合。
4. 日志聚合
许多人使用 Kafka 作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件，并将它们放在中央位置（可能是文件服务器或 HDFS）进行处理。Kafka 抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。
5. 流处理
kafka 中消息处理一般包含多个阶段。其中原始输入数据是从 kafka 主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题，例如，一个推荐新闻文章，文章内容可能从 “articles” 主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从 0.10.0.0 开始，轻量，但功能强大的流处理，就可以这样进行数据处理了。
除了 Kafka Streams，还有 Apache Storm 和 Apache Samza 可选择。
6. 事件采集
事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，kafka 支持这种非常大的存储日志数据的场景。
7. 提交日志
kafka 可以作为一种分布式的外部日志，可帮助节点之间复制数据，并作为失败的节点来恢复数据重新同步，kafka 的日志压缩功能很好的支持这种用法，这种用法类似于 Apacha BookKeeper 项目。
三、Kafka 架构深度剖析
1. Kafka 数据处理步骤
1.1 Producer 产生消息，发送到 Broker 中
1.2 Leader 状态的 Broker 接收消息，写入到相应 topic 中
1.3 Leader 状态的 Broker 接收完毕以后，传给 Follow 状态的 Broker 作为副本备份
1.4 Consumer 消费 Broker 中的消息
2. Kafka 核心组件
2.1 Producer：消息生产者，产生的消息将会被发送到某个 topic
2.2 Consumer：消息消费者，消费的消息内容来自某个 topic
2.3 Topic：消息根据 topic 进行归类，topic 其本质是一个目录，即将同一主题消息归类到同一个目录
2.4 Broker：每一个 kafka 实例（或者说每台 kafka 服务器节点）就是一个 broker，一个 broker 可以有多个 topic
2.5 Zookeeper： Zookeeper 集群不属于 kafka 内的组件，但 kafka 依赖 Zookeeper 集群保存 meta 信息，所以在此做声明其重要性。
3. broker 和集群
一个独立的 Kafka 服务器称为 broker，broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松处理数千个分区以及每秒百万级的消息量。
broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给 broker 和监控 broker。在集群中，一个分区从属于一个 broker，该 broker 被称为分区的首领。一个分区可以分配多个 broker，这个时候会发生分区复制。这种复制机制为分区提供了消息冗余，如果一个 broker 失效，其他 broker 可以接管领导权。不过，相关的消费者和生产者都要重新连接到新的首领。
4. Consumer 与 topic 关系
kafka 只支持 Topic
・每个 group 中可以有多个 consumer，每个 consumer 属于一个 consumer group；通常情况下，一个 group 中会包含多个 consumer，这样不仅可以提高 topic 中消息的并发消费能力，而且还能提高” 故障容错” 性，如果 group 中的某个 consumer 失效那么其消费的 partitions 将会由其它 consumer 自动接管。
・对于 Topic 中的一条特定的消息，只会被订阅此 Topic 的每个 group 中的其中一个 consumer 消费，此消息不会发送给一个 group 的多个 consumer；那么一个 group 中所有的 consumer 将会交错的消费整个 Topic，每个 group 中 consumer 消息消费互相独立，我们可以认为一个 group 是一个” 订阅” 者。
・在 kafka 中，一个 partition 中的消息只会被 group 中的一个 consumer 消费 (同一时刻)； 一个 Topic 中的每个 partions，只会被一个” 订阅者” 中的一个 consumer 消费，不过一个 consumer 可以同时消费多个 partitions 中的消息。
・kafka 的设计原理决定，对于一个 topic，同一个 group 中不能有多于 partitions 个数的 consumer 同时消费，否则将意味着某些 consumer 将无法得到消息，而处于空闲状态。
**kafka 只能保证一个 partition 中的消息被某个 consumer 消费时是顺序的；事实上，从 Topic 角度来说，当有多个 partitions 时，** 消息仍不是全局有序的。
5. Kafka 消息的分发
・Producer 客户端负责消息的分发
・kafka 集群中的任何一个 broker 都可以向 producer 提供 metadata 信息，这些 metadata 中包含 *” 集群中存活的 servers 列表”、“partitions leader** 列表”* 等信息；
・当 producer 获取到 metadata 信息之后，producer 将会和 Topic 下所有 partition leader 保持 socket 连接；
・消息由 producer 直接通过 socket 发送到 broker，中间不会经过任何” 路由层”。事实上，消息被路由到哪个 partition 上由 producer 客户端决定，比如可以采用”random””key-hash”” 轮询” 等。
・* 如果一个 topic** 中有多个 partitions, 那么在 producer 端实现”** 消息均衡分发”* 是必要的。
・在 producer 端的配置文件中，开发者可以指定 partition 路由的方式。
・Producer 消息发送的应答机制
设置发送数据是否需要服务端的反馈，有三个值 0,1,-1
0: producer 不会等待 broker 发送 ack
1: 当 leader 接收到消息之后发送 ack
2: 当所有的 follower 都同步消息成功后发送 ack
request.required.acks=0
6. Consumer 的负载均衡
当一个 group 中，有 consumer 加入或者离开时，会触发 partitions 均衡。均衡的最终目的，是提升 topic 的并发消费能力，步骤如下：
-
假如 topic1, 具有如下 partitions: P0,P1,P2,P3
-
加入 group A 中，有如下 consumer: C0,C1
-
首先根据 partition 索引号对 partitions 排序: P0,P1,P2,P3
-
根据 consumer.id 排序: C0,C1
-
计算倍数: M = [P0,P1,P2,P3].size/ [C0,C1].size, 本例值 M=2 (向上取整)
-
然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]