共计 3634 个字符,预计需要花费 10 分钟才能阅读完成。
一、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)]
如果本文对您有帮忙,欢送
关注
和点赞
`,您的反对是我保持创作的能源。转载请注明出处!