读一读Kafka源码(一) – Producer – 问题

源码浩繁, 就像被卷成一捆的毛线, 如果没有找到合适的线头, 很难捋清楚. 本文作为KafkaProducer分析的开篇, 重点提出Producer作为消息生产者必然面对的一些问题, 往后的文章我们将带着这些问题, 逐渐深入.

有问题不一定有答案, 没问题绝对没答案

KafkaProducer为何物?

如其名, 是Kafka的消息生产者(Producer), 早期版本只有scala的实现, 从0.8.2版本之后提供了对大多数人更友好的Java实现. 系列文章主要围绕0.11.0展开讨论. 但同时也部分涉及更早期的历史代码, 这样做的原因是早起版本代码量更少, 看起来轻松些. 同时任何功能都不是一簇而就的, 关注代码的迭代史可以更好地理解项目设计者的思路.

思路比结论重要.

消息生产者的原生问题

KafkaProducer作为客户端api, 生产中是被业务代码引用, 作为独立于Kafka Broker进程的独立进程代码运行的. 在这个背景下, 我们首先会生出以下疑问:

• Producer如何寻找数据的目标broker?
  • 问题的本质是集群信息的发现
  • 在实现上需要解答, “集群信息”包括什么, 从何处获取它, 怎么保证信息的及时性.
• Producer如何处理数据的传输?
  • Java的io框架主要包括BIO/NIO/AIO和三方实现包netty, dubbo等, 本项目的选择的是什么? 具体怎么实现?有什么优劣势?
  • 数据是在网络上传输的, 那么如何压缩/加密/校验就是最基础的问题
• Producer对数据的可靠性有哪些保证?
  • 消息发送状态的判断, ack机制
  • 丢包怎么处理? 重发消息幂不等的影响
  • 事务性的保证(At-least-once vs. Exactly-once)

kafka架构导致的后天问题

原生问题是伴随着需求的产生自然而来的, 所以上面提到的问题应该是所有分布式消息队列组件的生产者都必须要解决的基础问题. 在解决了上述问题之后, 将Kafka作为消息队列应用到普通的生产环境就应该没有大问题了. 但是每个设计都会有各自的特点, 这些特点即带来了独特的优势, 也难免会产生一些独特的难题.

• Kafka是根据partition来划分数据保存的, 每个broker维护若干partition leader负责直接处理来自Producer的数据写入请求. Producer如何协调负载均衡?

提出好的问题, 就已经成功了事情的1/10, 接下来的时间我会通过系列文章, 结合源码来解答这些问题, 您也可以回答此文的问题来看看自己的KafkaProducer的理解有几何.

Series Navigation

读一读Kafka源码(二) – Producer – 集群元数据 >>