咱们上一篇说了 聊聊 Kafka：Producer 源码解析，这一篇咱们来说下 Producer Metadata 的读取与更新机制。上一篇从宏观上介绍了 Producer 的宏观模型，其中通过 waitOnMetadata() 办法获取 topic 的 metadata 信息这一块货色很多，所以独自拎一篇进去讲。

sarama 是一个纯 Go 客户端库，用于解决 Apache Kafka（0.8 及更高版本）。它包含一个用于轻松生成和应用音讯的高级 API，以及一个用于在高级 API 有余时控制线路上的字节的低级 API。在github上stars上比拟多（举荐）。

老周这里编译 Kafka 的版本是 2.7，为啥采纳这个版本来搭建源码的浏览环境呢？因为该版本相对来说比拟新。而我为啥不必 2.7 后的版本呢？比方 2.8，这是因为去掉了 ZooKeeper，还不太稳固，生产环境也不太倡议应用，所以以 2.7 版本进行源码搭建并钻研。

cluster：kafka集群broker：kafka节点topic：主题partation：音讯分区（一个topic能够为多个partation组成）relica：正本（partation会有多个正本散布在多个beoker上，保障数据不丢）

在构建ProducerRecord的时候说过，ProducerRecord除了topic和value外，还有两个可选的，包含partition和key。在拉取到元数据后，咱们就开始依据分区来对这条音讯进行发送。

元素的拉取，是依据生产者的发送的topic来拉取的，并不是拉取所有的元数据，所以在发送音讯的时候，就会把这个topic寄存在topics中，这个topics就是记录了以后已有的topic，数据类型是map，他的key就是topic，value刚开始默认为-1。所以topic1发送的时候，就会在topics新增一个topic1->-1的键值对。

生产者发消息给Kafka，是须要晓得Kafka的ip、端口等节点信息，这些节点信息是元数据的一部分，属于元数据Metadata的Cluster的一部分。咱们每一个topic，在Kafka是分布式的模式寄存的，所以一个topic就会有多个分区，每个分区对应值着不同的ip、端口等信息。所以每个topic有多少分分区，每个分区的leader节点replica节点…

kafka也有生产者和消费者的概念，生产者把音讯发给kafka，消费者从kafka拿音讯进行生产，这个跟之前的activemq和rabbitmq相似。咱们从生产者发消息开始，探讨kafka的整个流程。这里的版本是0.10.1.0。

当开发者通过API生产Twitter的公共数据时，他们须要取得可靠性、速度和稳定性方面的保障。因而，在不久前，咱们推出了Account Activity Replay API帮忙开发者们晋升他们零碎的稳定性。这个API是一个数据恢复工具，开发者能够用它来检索最早产生在5天前的事件，复原因为各种起因（包含在实时传递时忽然产生的服务器中断）…

数据失落是一件十分重大的事件事，针对数据失落的问题咱们须要有明确的思路来确定问题所在，针对这段时间的总结，我集体面对kafka数据失落问题的解决思路如下：