apache kafka中的术语

mklgxw1f  于 2021-06-07  发布在  Kafka
关注(0)|答案(1)|浏览(298)

我阅读了apachekafka文档和更多的文章,开始了解kafka是什么,以及如何在我的应用程序中使用它。然而,我在这一点上非常困惑。
我无法理解分区和代理之间的区别。
Kafka为可靠性提供了一个复制因素。这些复制的数据是否存在于同一台计算机上?
一个{高层次,低层次}+{生产者,消费者}之间的区别
如果Kafka不储存消费者的立场,最好的储存方法是什么?人们是否使用数据库,或者他们可能将其作为本地信息存储到客户端。
使用kafka和nodejs(为数据提供restapi)构建pub子系统是个好主意吗?
有人能指引我往这个方向走吗?请评论,如果你想我添加任何其他相关信息,有助于更好地提供解决方案。
提前谢谢。

46qrfjad

46qrfjad1#

这是一个很好的机会来温习我的Kafka知识,所以我很抱歉,如果这有点长。
这里的大多数答案都来自您链接的文档,或者通过谷歌搜索相关文档。
既然您表示希望使用node.js,我将提供一些关于可以说是最好的(据我所知)kafka 0.9.0客户机no kafka的参考,并在最后一节中进行讨论。
问题1
我无法理解分区和代理之间的区别
经纪人:
代理是运行kafka示例的服务器,如引言所述:
kafka作为一个由一个或多个服务器组成的集群运行,每个服务器都称为代理。
分区:
向主题发布和使用消息。可以对主题进行分区,如果您运行的集群中有>1个代理,则分区将分布在代理(kafka服务器)上。
每个分区都是一个有序的、不可变的消息序列,不断地附加到。。。
这使您能够平衡高吞吐量主题的负载。您可以根据需要使用一个、多个或所有分区。哪个消息发往哪个分区是由您选择的分区策略决定的(例如,散列密钥、在发布时设置分区等)。
问题2
Kafka为可靠性提供了一个复制因素。这些复制的数据是否存在于同一台计算机上?
如果你的意思是在同一台机器上复制,那么不,这充其量是可疑的,因为它无法承受简单的服务器崩溃。复制因子决定将在主题的每个分区上复制多少个代理(服务器)。所以——复制因子3意味着每个分区都在3个代理上,其中一个作为引导者(接受读/写),其余两个复制引导者,准备在当前引导者失败时自动接受引导者状态。创建主题时,复制因子必须小于集群上的代理数。
从介绍中:
对于复制因子为n的主题,我们最多可以容忍n-1个服务器故障,而不会丢失提交到日志的任何消息。
通过在一台机器上运行多个代理(可能是在不同的磁盘上,或者出于任何原因),您可以在一台机器上获得多个副本。
问题3
一个{高层次,低层次}+{生产者,消费者}之间的区别
实际上只有一个producerapi(存在一个遗留的scala客户机)。有三种消费API。旧的高级和低级api以及新的统一api。如果您运行的是kafka 0.9.0或更高版本(如果您刚开始使用的话,您很可能希望使用新的统一api)。它包括旧的使用者api不可用的新特性(例如,在0.9.0中引入的安全特性),并且不需要旧的特性(除非您选择的库不支持新的api,这很可能意味着您应该切换)。
没有kafka支持simpleconsumerapi,它是iirc对旧的低级api建模的。它可以很好地用于简单的测试,但是我强烈推荐groupconsumerapi,它使用新的统一api。它的优点之一(提交补偿)将在下一个问题中讨论。
问题4
如果Kafka不储存消费者的立场,最好的储存方法是什么?人们是否使用数据库,或者他们可能将其作为本地信息存储到客户端。
你真的可以随心所欲地存储它们(在磁盘上等)。新的统一用户api自动保存用户的偏移量(它已发送的消息)。您的使用者还应在成功处理消息后提交其最新处理的偏移量(no kafka groupconsumer中的consumer.commitofset),因此,如果您在重新启动或其他操作后重新连接使用者,您将获得您自己标记为未成功使用的最新消息。
这也是使用新的统一消费者api的众多优秀理由之一。
偏移量存储在一个高度可用(复制)的分区主题中,并由kafka缓存。您还可以配置用于偏移保存的选项(搜索带有偏移的选项)。或偏移量。在这个链接后面。
一个用于将使用者偏移提交给zookeeper,这是kafka在分布式服务(如配置)中依赖的服务,但是zookeeper不能很好地扩展到许多写入,并且已经从kafka的api中抽象出来。这就是《无Kafka》中的simpleconsumer如何保存其偏移量。
问题5
使用kafka和node.js(为数据提供restapi)构建pub子系统是个好主意吗?
那样做没有错。最近我自己也用node.js+kafka做了一些演示,非常喜欢。如上所述,对于kafka>0.9,我建议使用no-kafka库,但是旧的(对于>0.8)kafka节点也可以使用,因为0.9是向后兼容的。即使没有其他原因,我也不会选择kafka来支持统一的消费者api。
除了使用node.js创建面向客户端的接口外,还可以使用它轻松完成光流处理(例如,丰富和重新格式化收集的事件)。例如,可以将Kafka日志格式化为数据库。
使用node.js可能无法最好地完成繁重的流处理,因为实现资源管理、容错等将是一项艰巨的任务,而且对于这些任务有很好的流处理框架(samza、spark等)。是的,它们使用不同的语言,但是您可能会找到适合您的框架。如果您熟悉开发和部署高性能、优化的节点应用程序,您甚至可以使用node.js创建繁重的任务原型。

相关问题