kafka 的network

好了 ， 接着上一章 ， 我们回到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 中作为参数返回给客户端。