好了 ， 接着上一章 ， 我们回到kafka的 kafkaserver 这个重量级的类。
val handlers = new KafkaRequestHandlers(logManager)
socketServer = new SocketServer(config.port,
config.numThreads,
config.monitoringPeriodSecs,
handlers.handlerFor,
config.socketSendBuffer,
config.socketReceiveBuffer,
config.maxSocketRequestSize)
在初始化zk连接， 加载topic信息之后。kafka开始跟做一些io的东西。个人对这部分还是很感兴趣的。让我们点进去看一看。
注释写的很精彩啊：
/** * An NIO socket server. The thread model is * 1 Acceptor thread that handles new connections * N Processor threads that each have their own selectors and handle all requests from their connections synchronously */
他都已经说了，这是 NIO 线程模型是 单线程负责处理所以的连接。n个线程异步处理这些连接。
从这个注释入手，我们看一看 Acceptor 和 Processor 是如何实现的。
/**
* Thread that accepts and configures new connections. There is only need for one of these
*/
private[kafka] class Acceptor(val port: Int, private val processors: Array[Processor], val sendBufferSize: Int, val receiveBufferSize: Int) extends AbstractServerThread {
/**
* Accept loop that checks for new connection attempts
*/
def run() {
val serverChannel = ServerSocketChannel.open()
serverChannel.configureBlocking(false)
serverChannel.socket.bind(new InetSocketAddress(port))
serverChannel.register(selector, SelectionKey.OP_ACCEPT);
logger.info("Awaiting connections on port " + port)
startupComplete()
var currentProcessor = 0
while(isRunning) {
val ready = selector.select(500)
if(ready > 0) {
val keys = selector.selectedKeys()
val iter = keys.iterator()
while(iter.hasNext && isRunning) {
var key: SelectionKey = null
try {
key = iter.next
iter.remove()
if(key.isAcceptable)
accept(key, processors(currentProcessor))
else
throw new IllegalStateException("Unrecognized key state for acceptor thread.")
// round robin to the next processor thread
currentProcessor = (currentProcessor + 1) % processors.length
} catch {
case e: Throwable => logger.error("Error in acceptor", e)
}
}
}
}
logger.debug("Closing server socket and selector.")
Utils.swallow(logger.error, serverChannel.close())
Utils.swallow(logger.error, selector.close())
shutdownComplete()
}
如果明白 java NIO 的相关部分，就会比较容易看懂这部分，忘了的上网搜搜。 一段标准的java server端的NIO 的操作， 绑定端口，注册事件，轮询 selector。如果有连接事件，就交给 processor 来处理。 简单而强有力的做法。下面看看Processor 是咋实现的。
private val newConnections = new ConcurrentLinkedQueue[SocketChannel]();
private val requestLogger = Logger.getLogger("kafka.request.logger")
override def run() {
startupComplete()
while(isRunning) {
// setup any new connections that have been queued up
configureNewConnections()
val ready = selector.select(500)
if(ready > 0) {
val keys = selector.selectedKeys()
val iter = keys.iterator()
while(iter.hasNext && isRunning) {
var key: SelectionKey = null
try {
key = iter.next
iter.remove()
if(key.isReadable)
read(key)
else if(key.isWritable)
write(key)
else if(!key.isValid)
close(key)
else
throw new IllegalStateException("Unrecognized key state for processor thread.")
} catch {
case e: EOFException => {
logger.info("Closing socket connection to %s.".format(channelFor(key).socket.getInetAddress))
close(key)
}
case e: InvalidRequestException => {
logger.info("Closing socket connection to %s due to invalid request: %s".format(channelFor(key).socket.getInetAddress, e.getMessage))
close(key)
} case e: Throwable => {
logger.error("Closing socket for " + channelFor(key).socket.getInetAddress + " because of error", e)
close(key)
}
}
}
}
}
logger.debug("Closing selector.")
Utils.swallow(logger.info, selector.close())
shutdownComplete()
}
好 ， 咱们看看首先他有一个newConnections队列 用来存储SocketChannel 对象，实际上可以看成缓存请求的消息队列。
在 run方法中， 先清空了这个队列，同时在selector 中注册这些事件。然后又是nio的一段标准的程序。看看read 方法中都干了什么：
/**
* Handle a completed request producing an optional response
*/
private def handle(key: SelectionKey, request: Receive): Option[Send] = {
val requestTypeId = request.buffer.getShort()
if(requestLogger.isTraceEnabled) {
requestTypeId match {
case RequestKeys.Produce =>
requestLogger.trace("Handling produce request from " + channelFor(key).socket.getRemoteSocketAddress())
case RequestKeys.Fetch =>
requestLogger.trace("Handling fetch request from " + channelFor(key).socket.getRemoteSocketAddress())
case RequestKeys.MultiFetch =>
requestLogger.trace("Handling multi-fetch request from " + channelFor(key).socket.getRemoteSocketAddress())
case RequestKeys.MultiProduce =>
requestLogger.trace("Handling multi-produce request from " + channelFor(key).socket.getRemoteSocketAddress())
case RequestKeys.Offsets =>
requestLogger.trace("Handling offset request from " + channelFor(key).socket.getRemoteSocketAddress())
case _ => throw new InvalidRequestException("No mapping found for handler id " + requestTypeId)
}
}
val handler = handlerMapping(requestTypeId, request)
if(handler == null)
throw new InvalidRequestException("No handler found for request")
val start = time.nanoseconds
val maybeSend = handler(request)
stats.recordRequest(requestTypeId, time.nanoseconds - start)
maybeSend
}
关键是匹配事件之后，他们都干了什么。由于对scala 语法不是那么纯熟，不知道咱们的就调用到了
var response: MessageSetSend = null
try {
trace("Fetching log segment for topic, partition, offset, maxSize = " + fetchRequest)
val log = logManager.getLog(fetchRequest.topic, fetchRequest.partition)
if (log != null) {
response = new MessageSetSend(log.read(fetchRequest.offset, fetchRequest.maxSize))
BrokerTopicStat.getBrokerTopicStat(fetchRequest.topic).recordBytesOut(response.messages.sizeInBytes)
BrokerTopicStat.getBrokerAllTopicStat.recordBytesOut(response.messages.sizeInBytes)
}
else
response = new MessageSetSend()
}
也就是说 在消费消息的时候是把 内容封装到 MessageSetSend 中作为参数返回给客户端。