librdkafka-producer源码阅读学习(1)

    业务需要，系统中要使用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。

    以上就是这一节的内容，如有错误还望指出与海涵。