Jafka源码粗略解读之三-producer

资料

今天看到研究Jafka的人还挺多的，比较优秀的是@FrankHui的Kafka系列文章，还有@rockybean 的博客。这两个博客都写的很详细，条理清晰，图文并茂，比起我这种走马观花，笔记式的记录要好得多了。

不过其实读源码每个人侧重点都不同，我还是继续记录我的。

作为一个实用主义者，我觉得读源码有几种目的：

1. 实际使用到该项目，想要弄清其原理，乃至于需要做定制化的
2. 想要学习其设计方法、架构思想的
3. 想要学习到一些代码实现上的技巧

因为项目中也没有用到Jafka，而是公司内部基于mongodb和netty写的一个MQ，其实我倒是更倾向于3和2，然后再带着想法回头改进自己的。既然已经写了是粗略解读，倒是不怕人指责了。

代码

Producer的入口可以看ProducerTest类。

根据配置，send()可以使用sync和async方式。

BlockingChannel是封装了网络连接的类，底层是NIO的SocketChannel。

这里颇有意思的是BlockingChannel的send方法：

public int send(BoundedByteBufferSend bufferSend) throws IOException {
    if (!isConnected()) {
        throw new ClosedChannelException();
    }
    return bufferSend.writeCompletely(writeChannel);
}

一般在涉及IO的开发中，我们都是直接拿一个流，然后用统一的序列化方式，最后写入buffer:

writeChannel.write(encoder.encode(object))

而Jafka里的BoundedByteBufferSend很显然是Java里面动作名词化的实践之一，bufferSend.writeCompletely(writeChannel)的含义是：由BoundedByteBufferSend来决定如何组织数据并写入缓存，而不是在负责网络IO的BlockingChannel类里统一做处理。这样的方式引入了OO的特性，更为优雅和易维护。同样，Request也使用了这样的方法writeTo。

MessageSet是打包消息和传输的类。Jafka压缩消息的算法目前只实现了GZip，GZip在JDK里可以通过GZIPInputStream实现。

协议

个人对于网络协议这一块比较感兴趣，既然看到了Message，就顺带对Jafka的传输协议进行一下分析。Jafka所用的协议应该是完全兼容Kafka的。

在Jafka里，所有的请求都会首先带上4个字节的长度，然后才是内容(代码参考BoundedByteBufferSend里的sizeBuffer和buffer)：

对于Producer，Producer的message格式如下(代码参考MessageSet.createByteBuffer())：

在不压缩的情况下，消息仍然是按照4byte长度+内容的方式发送。而压缩是将所有消息混合压缩的。