kafka.network.SocketServer分析
当Kafka启动时，会启动这个SocketServer来接收客户端的连接，处理客户端请求，发送响应。
这个类的注释说明了这个socket server的结构
/**
* An NIO socket server. The threading model is
* 1 Acceptor thread that handles new connections
* N Processor threads that each have their own selector and read requests from sockets
* M Handler threads that handle requests and produce responses back to the processor threads for writing.
*/
即
1个Acceptor，用来接收新的连接。
N个Processor，每个Processor有自己的selector，Processor从sockets里读取请求，以及写response到sockets。
M个Handler用来处理请求，并且产生response给Processor。
其中：
Acceptor监听新连接，如果有新连接，就分配给某个Processor，这个Processor会把这个SocketChannel注册给自己的Selector，注册为OP_READ。当这个SocketChannel可读，就从中读数据，产生Request，然后放入到RequestChannel的队列中。
Processor还会从新RequestChannel中不断取Response，然后把Response对应的SocketChannel在自己的Selector上注册为OP_WRITE，当这个SocketChannel可写，就把数据写入。然后把这个SocketChannel注册为OP_READ，继续监听请求。
其中使用的类主要包括：
Acceptor : 它是一个SocketServer, 接受新的连接，并且分配连接给Processor
Processor: 读取请求，发送响应
Handler: 处理请求，产生响应。这里的Handler由kafka.server.RequestHandler实现。
RequestChannel: 它包括了一个request queue 和 一个 response queue. 是Handler和Processsor交互时使用的队列。Request由Processor放入RequestChannel, 由Handler取出，然后把Response放回RequestChannel.
Acceptor在接受连接后，就把相当的SocketChannel设成非阻塞模式。因此Processor对这些SocketChannel的读写都是使用Selector，采用非阻塞的处理模式。
问题：
(1) Acceptor是如何把新来的连接分配给对应的Processor，这个算法是什么？是round robin吗？
在每接收一个请求后，调用
// round robin to the next processor thread
currentProcessor
= (
currentProcessor
+
1
) %
processors
.length
而每个新的socketChannel分配的方式为：
accept(
key
,
processors
(
currentProcessor
))
这个key就是Acceptor的Selector返回的SelectionKey
因此，socketChannel分配给Processor的过程是round robin的
(2) Processor应该把对应的SocketChannel在自己的Selector上如何注册？
首先，Acceptor会把这个SocketChannel传送给对应的Processor:
在收到一个新的连接时，Acceptor对它调用自己的accept方法
accept(key: SelectionKey,
processor
: Processor)
为了使用Selector,它会将新到的SocketChannel配置为非阻塞模式，然后配置sendBufferSize
然后调用Processor的accept方法。
然后，Processor会把这个SocketChannel加入到自己的newConnection队列中。
在每个Processor内部有一个ConcurrentLinkedQueue
private
val
newConnections
=
new
ConcurrentLinkedQueue [SocketChannel]()
然后Processor会处理这个新连接。
Processor的accept方法实现为：
newConnections
.add(socketChannel)
wakeup()
即，将新的socketChannel加到队列中，然后wakeup自己的selector。
这会使得select从阻塞状态醒来，执行一次select()外层的while循环。在每次循环的开始，都会处理新的connection。
configureNewConnections()
这个方法的实现为：
while
(
newConnections
.size() >
0
) {
val
channel
=
newConnections
.poll()
channel
.register(
selector
, SelectionKey.
OP_READ
)
}
这个socketChannel被注册为OP_READ
于是，当这个连接有请求过来，Processor的Selector就会从select方法中返回，Processor开始读取请求。
(3) Processor如何读取请求？
首先，如果一个SocketChannel可读。Processor在自己run方法的while循环中会从select方法中获得对应的SelectionKey。
在Processor的run方法的while循环中：
if
(
key
.isReadable)
read(
key
)
read方法会从SocketChannel中读取并构造Request对象，然后把它发送给RequestChannel。
它的实现为：
/*
* Process reads from ready sockets
*/
def read(key: SelectionKey) {
val socketChannel = channelFor(key) //获取可读的SocketChannel
var receive = key.attachment.asInstanceOf[Receive] //获取attach到SelectionKey的Receive对象
if(key.attachment == null) { //如果attachment是空，说明这是第一次读，就新建一个Receive对象，attach到这个SocketChannel的SelectionKey上。如果不是空，说明之前已经从中读了一些数据，只是没读完。
receive = new BoundedByteBufferReceive(maxRequestSize)
key.attach(receive)
}
val read = receive.readFrom(socketChannel) //从SocketChannel中读数据
val address = socketChannel.socket.getRemoteSocketAddress();
trace(read + " bytes read from " + address)
if(read < 0) { //如果读的数据数小于0，就关闭socket连接。实际上从BoundedByteBufferReceive的实现来看，read的值不会小于0
close(key)
} else if(receive.complete) {//如果读完了，就构造request,发送给requestChannel
val req = RequestChannel.Request(processor = id, requestKey = key, buffer = receive.buffer, startTimeMs = time.milliseconds, remoteAddress = address)
requestChannel.sendRequest(req)
key.attach(null) //取消attach的Receive对象
// explicitly reset interest ops to not READ, no need to wake up the selector just yet
key.interestOps(key.interestOps & (~SelectionKey.OP_READ))//显示地把这个SocketChannel设为非OP_READ，等到Response发给这个SocketChannel以后，它会被再设为OP_READ，以继续处理来自这个SocketChannel的请求。
} else {//如果没有读完，就把这个SocketChannel注册为OP_READ，然后wakeup对应的selector，继续从SocketChannel中读数据。所以下一次再处理这个SocketChannel时，attach到它的SelectionKey的Receive对象就不是空了。
// more reading to be done
trace("Did not finish reading, registering for read again on connection " + socketChannel.socket.getRemoteSocketAddress())
key.interestOps(SelectionKey.OP_READ)
wakeup()
}
}
那么BoundedByteBufferReceive是如何知道一个请求读没读完呢？
原来每个Request的前4个字节标识了这个Request有多长，BoundedByteBufferReceive从SocketChannel中读取前4个字节，转换成整形，以这个整数为大小构造一个ByteBuffer，如果这个ByteBuffer没有写满，就说明请求的内容还没有读完。receive.complete就不被设为true，否则就说明这个Request已经从channel中完全读出。
if(!contentBuffer.hasRemaining) {
contentBuffer.rewind()
complete = true
}
在Kafka的
Wire Format中有说明：
Request Header (all single non-multi requests begin with this)
012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| REQUEST_LENGTH |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| REQUEST_TYPE | TOPIC_LENGTH |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ // TOPIC (variable length) /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| PARTITION |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(4) Processor如何接收Handler产生的response?
它会在run方法的while循环中获取RequestChannel中的Response，然后把它写到SocketChannel。
中间的机制和Request类似。