资料
今天看到研究Jafka的人还挺多的，比较优秀的是@FrankHui的，还有@rockybean 的。这两个博客都写的很详细，条理清晰，图文并茂，比起我这种走马观花，笔记式的记录要好得多了。
不过其实读源码每个人侧重点都不同，我还是继续记录我的。
作为一个实用主义者，我觉得读源码有几种目的：
- 实际使用到该项目，想要弄清其原理，乃至于需要做定制化的
- 想要学习其设计方法、架构思想的
- 想要学习到一些代码实现上的技巧
因为项目中也没有用到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长度+内容的方式发送。而压缩是将所有消息混合压缩的。