一、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)]
如果本文对您有帮忙，欢送
关注和点赞`，您的反对是我保持创作的能源。转载请注明出处！