业务需要,系统中要使用librdkafa。主要是关于producer的部分。说实话,模仿官方的demo也写出来了,并引入到已有的系统中。但出于系统稳定性的考虑,我需要对使用到kafka部分的程序可能出现的异常作出全面的考虑。网上翻阅各种博客,加之自己的理解,也算是对producer有了点粗浅的认知。
这一节我打算整体的说一下Kafka的运作过程,侧重于producer端的叙说。
Kafka是一个数据传输平台。数据发送方,称之为producer,将数据发送到Kafka的服务器上。数据接收方,称之为consumer,从Kafka服务器上获取数据并使用。Kafka的服务器称之为broker,服务器需要相应的管理者,这个管理者称之为zookeeper。简单地概括一下这个过程就是,producer产生数据并推送到broker上,consumer可以从这broker上获取数据并“消费”。
其实之前的过程有一点说的并不准确的,producer产生的数据并不是推到broker上,而是推送到topic的某一个partition上,但broker因为是持有了那一个topic,因此说producer推到broker上也是没错的。partition在物理上的表现就是一个文件目录,我们推送到这个partition的数据就存储在这个文件夹中。用图示表示一下producer,topic,broker,zookeeper,consumer的关系如下图。(图是我盗的,不过是我认为可以很好的表述这些对象关系的图)
之前是从整体上介绍一下kafka的运作,现在我重点讲述一下从producer到broker的这一流程。
假设当前我们使用的topic有2个partition—p1和p2。相应的,有两个broker—b1和b2。(replication就暂不表述了,不关键)如图示。
现在我有一个应用application作为producer向Kafka推送数据,那么具体它要怎么做呢?不准确地来说,它要经过两个步骤—获取metadata、发送数据。当producer向topic推送消息时,它需要知道向哪一个broker,哪一个partition推送。这时它会检查一个metadata_cache的数据,由此获取相关信息。而现在,我们的application是首次访问metadata_cache,这个cache自然是空的,因此它需要向已知的broker—b1和b2发消息,b1和b2会返回topic相关的信息,包括partition、leader、isr等等。producer获悉这些信息后就可以向topic推送信息了。之后再推送信息就从metadata_cache中获取即可。
上述事例中broker是和topic有一定联系的,那么producer获取的metadata也理所当然能用。那么,如果producer发送的broker和topic毫无关联时,比如同处一个zookeeper下的b3 broker,此时producer还能正确的推送消息到b1、b2吗?答案是可以。
事实上,(这里,我只能大概这么说)broker会向所有同处一个zookeeper下的broker发送消息来获取producer推送的topic的相关的信息,然后返回这个topic的metadata给producer。
以上就是这一节的内容,如有错误还望指出与海涵。