共计 4382 个字符,预计需要花费 11 分钟才能阅读完成。
上面给出 Kafka 一些重要概念,让大家对 Kafka 有个整体的意识和感知,前面还会具体的解析每一个概念的作用以及更深刻的原理
• Producer:音讯生产者,向 Kafka Broker 发消息的客户端。
• Consumer:音讯消费者,从 Kafka Broker 取音讯的客户端。
• Consumer Group:消费者组(CG),消费者组内每个消费者负责生产不同分区的数据,进步生产能力。一个分区只能由组内一个消费者生产,消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。
• Broker:一台 Kafka 机器就是一个 Broker。一个集群由多个 Broker 组成。一个 Broker 能够包容多个 Topic。
• Topic:能够了解为一个队列,Topic 将音讯分类,生产者和消费者面向的是同一个 Topic。
• Partition:为了实现扩展性,进步并发能力,一个十分大的 Topic 能够散布到多个 Broker(即服务器)上,一个 Topic 能够分为多个 Partition,每个 Partition 是一个 有序的队列。
• Replica:正本,为实现备份的性能,保障集群中的某个节点产生故障时,该节点上的 Partition 数据不失落,且 Kafka 依然可能持续工作,Kafka 提供了正本机制,一个 Topic 的每个分区都有若干个正本,一个 Leader 和若干个 Follower。
• Leader:每个分区多个正本的“主”正本,生产者发送数据的对象,以及消费者生产数据的对象,都是 Leader。
• Follower:每个分区多个正本的“从”正本,实时从 Leader 中同步数据,放弃和 Leader 数据的同步。Leader 产生故障时,某个 Follower 还会成为新的 Leader。
• Offset:消费者生产的地位信息,监控数据生产到什么地位,当消费者挂掉再从新复原的时候,能够从生产地位持续生产。
• ZooKeeper:Kafka 集群可能失常工作,须要依赖于 ZooKeeper,ZooKeeper 帮忙 Kafka 存储和治理集群信息。
1. 音讯和批次
Kafka 中的数据单元称为音讯(message)。如果你对数据库十分理解,那么您能够将其视为与数据库中行或记录相似。就 Kafka 而言,音讯只是一个字节数组,因而其中蕴含的数据对 Kafka 没有特定的格局或含意。音讯能够具备可选的元数据位,其被称为 key。key 也是一个字节数组,与音讯一样,对 Kafka 没有特定含意。当音讯以更受管制的形式写入分区时,应用 key。最简略的计划是生成 key 的统一哈希,而后通过获取哈希模的后果(主题中的分区总数)来抉择该音讯的分区号。这可确保具备雷同 key 的音讯始终写入同一分区。
为了提高效率,将音讯分批写入 Kafka。批处理只是一组音讯,所有音讯都生成到同一主题和分区。每条音讯通过网络进行独自的往返会导致适度的开销,而将音讯一起收集到一个批处理中则会缩小这种状况。当然,这是提早和吞吐量之间的衡量:批次越大,每单位工夫能够解决的音讯越多,但单个音讯流传所需的工夫就越长。批次通常也是压缩的,以一些解决能力为代价提供更无效的数据传输和存储。
1.1 音讯
是 Kafka 中的最小数据单元,类比“数据库”中的一条记录;音讯由字节数组组成,Kafka 没有具体的格局和定义,然而客户端提供的音讯定义中有一组可选的数据单元:
public final class ProducerRecord<K, V> {
private final String topic; // 音讯主题
private final Integer partition; // 音讯分区
private final K key; // 音讯的键
private final V value; // 音讯值
}
在以上的字段中,只有音讯主题是必须的,标识这个音讯的分类。
2.2 批次
同咱们常说的分批解决思维中的批次概念是统一的;从根本上来讲都是为了缩小耗费,晋升效率。
如果每一个生产者产生一条音讯,咱们就写到网络中,会带来大量的开销,所以将音讯分批次来传递;当然分批会带来提早,这样就须要在提早和吞吐量之间做一个衡量,Kafka 提供参数来给开发者优化这种均衡。
单个批次音讯越多,提早越大,同时音讯会被压缩,来晋升数据的传输和存储能力,当然压缩更耗费 CPU。
批次外面的音讯都是属于同一个主题中的同一个分区,这样能够保障一次发送一批音讯时的网络开销最小。
2. 模式(Schemas)
尽管音讯是 Kafka 自身的不通明字节数组,但倡议在音讯内容上加上额定的构造或模式,以便易于了解。音讯架构有许多选项,具体取决于您的应用程序的个性化需要。简略零碎,例如 Javascript Object Notation(JSON)和可扩大标记语言(XML),易于应用且易于浏览。然而,它们不足弱小的类型解决和模式版本之间的兼容性等性能。许多 Kafka 开发人员都赞成应用 Apache Avro,这是一个最后为 Hadoop 开发的序列化框架。Avro 提供紧凑的序列化格局; 与音讯无效负载拆散的模式,不须要在更改时生成代码; 弱小的数据类型和模式演变,兼具向后和向前兼容性。
统一的数据格式在 Kafka 中很重要,因为它容许写入和读取音讯拆散。当这些工作严密耦合时,必须更新订阅音讯的应用程序以解决新数据格式,与旧格局并行。只有这样能力更新公布音讯的应用程序以应用新格局。通过应用定义良好的模式并将它们存储在一个通用的存储库中,能够无需协调地了解 Kafka 中的音讯。
3. 主题和分区
Kafka 里的音讯用主题进行分类(主题好比数据库中的表),主题下有能够被分为若干个分区(分表技术)。分区实质上是个提交日志文件,有新音讯,这个音讯就会以追加的形式写入分区(写文件的模式),而后用先入先出的程序读取。
3.1 主题
是音讯的分类标识,相似于文件系统中的文件夹
3.2 分区
是一个主题的队列,同一个主题会蕴含若干分区,每一个分区都是一个提交记录,音讯会被追加到分区中,在一个分区中保障程序,以先入先出的程序被生产。
Kafka 为每个分区中保护着一个偏移量,偏移量记录着以后分区的生产记录,偏移量保留在分布式协同服务器 ZooKeeper 上。
分区在 Kafka 中有着重要的意义,Kafka 通过分区来实现数据冗余和主题的横向扩大;多个分区能够散布在不同的 kafka 服务端机器上,这使主题也能够横跨多个服务器存在,保障了分布式的能力;
在音讯中讲到了音讯的键,在音讯没有配置键的时候,生产者会把音讯平衡的写入到各个分区。当咱们须要把特定的音讯写入到固定的分区时,能够通过音讯的键和分区器来实现,分区器会将键生成成散列值,并映射到各个分区上。
为了大量的音讯能负载扩散,要求主题的分区数要大于以后 Kafka 的 broker 服务器数量,这样能力保障所有每个 broker 能分担到音讯的压力。在理论生产中,咱们能够减少分区来给主题扩容,然而不能缩小分区。
选定分区数量是一个须要教训的事件,须要思考多个因素:
- 主题须要多大的吞吐
- 单个分区的最大吞吐量多少
- 每个 broker 上领有的分区数量,这须要考量磁盘和网络带宽
- 单个分区上领有的分区也不能太多,毕竟分区越多内存也越大,从新选举的工夫也越长
须要留神的是,如果应用了音讯的键来管制音讯写入分区,那么减少主题时就须要谨慎了,因为这会带来 rehash 的问题。
4. 生产者和消费者
Kafka 客户端是零碎用户,有两种根本类型:生产者和消费者。还有高级客户端 API – 用于数据集成的 Kafka Connect API 和用于流解决的 Kafka Streams。高级客户端应用生产者和消费者作为构建块,并在顶部提供更高级别的性能。
4.1 生产者
生产者发明新的信息。在其余公布 / 订阅零碎中,这些能够称为发布者或编写者。通常,将为特定主题生成音讯。默认状况下,生产者不关怀特定音讯写入的分区,并将平衡地均衡主题的所有分区上的音讯。在某些状况下,生产者会将音讯定向到特定分区。这通常应用音讯 key 和分区程序来实现,该分区程序将生成 key 的散列并将其映射到特定分区。这确保了应用给定 key 生成的所有音讯都将写入同一分区。生产者还能够应用遵循其余业务规定的自定义分区程序将音讯映射到分区。
4.2 消费者
消费者浏览音讯。在其余公布 / 订阅零碎中,这些客户端能够被称为订阅者或读者。消费者订阅一个或多个主题,并按音讯的生成程序读取音讯。消费者通过跟踪音讯的偏移来跟踪它曾经耗费了哪些音讯。偏移量 (Offset) 是元数据 – 一个一直减少的整数值 – Kafka 在生成时增加到每个音讯中。给定分区中的每条音讯都有惟一的偏移量。通过在 Zookeeper 或 Kafka 自身中存储每个分区的最初耗费音讯的偏移量,消费者能够进行并重新启动而不会失落其地位。
消费者负责消费者群组的一部分工作,消费者群组是一起工作以生产主题的一个或多个分区。该小组确保每个分区仅由一名成员生产。在单个组中有三个消费者应用主题。其中两个消费者别离在一个分区工作,而第三个消费者在两个分区工作。消费者对分区的映射通常称为消费者对分区的所有权。
不同的消费者群组能够读取同一个主题,但对于同一个群组中不同消费者不能读取雷同分区
通过这种形式,消费者能够横向扩大以生产具备大量音讯的主题。此外,如果单个使用者失败,则该组的其余成员将从新均衡正在应用的分区以接管短少的成员。
5. 保留音讯
保留音讯是 Kafka 的一个重要个性。Kafka broker 默认的音讯保留策略有两种。
- 保留一段固定的工夫。比方 7 天
- 保留到音讯达到肯定大小的字节数,如 1GB 当达到下限后,旧的音讯会过期从而被删除。所以在任何时刻,可用音讯的总量不会超过配置参数所指定的大小。
6. 多集群
随着 Kafka 部署的增长,领有多个集群通常是无利的。有几个起因能够解决这个问题:
• 拆散数据类型
• 为平安要求隔离
• 多个数据中心(劫难复原)
特地是在解决多个数据中心时,通常须要在它们之间复制音讯。通过这种形式,在线应用程序能够拜访两个站点的用户流动。例如,如果用户更改其配置文件中的公共信息,则无论显示搜寻后果的数据中心如何,都须要显示该更改。或者,能够将监控数据从许多站点收集到剖析和警报系统所在的单个核心地位。Kafka 集群中的复制机制仅设计用于单个集群,而不是多个集群之间。
Kafka 我的项目包含一个名为 MirrorMaker 的工具,用于此目标。MirrorMaker 的外围是 Kafka 消费者和生产者,与队列链接在一起。音讯从一个 Kafka 集群中耗费并为另一个集群生成。应用 MirrorMaker 架构,将来自两个本地群集的音讯聚合到聚合群集中,而后将该群集复制到其余数据中心。应用程序的简略个性覆盖了它在创立简单数据管道方面的能力。
如果本文对您有帮忙,欢送
关注
和点赞
`,您的反对是我保持创作的能源。转载请注明出处!