一、ACL检查流程解析 一起看一下kafka server的启动与监听流程： Kafka -> KafkaServer -> SocketServer、KafkaRequestHandler 其中KafkaServer做相关的初始化，包括SocketServer 与 handler pool。 SocketServer的start up流程 看一下acceptor acceptor实际执行流程：监听网络事件，提交给processor处理 看一下processor，截取KafkaServer代码：这边的numIoThreads就是配置的具体处理线程数量。KafkaApis封装具体的各api的处理逻辑，handler pool则是工作线程池。 看看kafkaApis 接着看pool中每个线程的while循环，从request队列拿一个请求，调用apis处理，结果发送给对应channel。 request的入队，见SocketServer，这里也可以看到acl使用的principal和sasl认证是同一个。 之前我们看到，在selector做channel初始化时，已经做了sasl认证。那acl在哪里处理？KafkaApis。以offset commit为例 看一下，这边的authorize，各api共用的方法。构建resource pattern，即资源描述，以及对应的操作。然后使用authorizer实现类进行处理。 看一下鉴权实现类AclAuthorizer，初始化，主要是zk相关的监听，因为token,user,acl都存在zk。 遍历每个action 每个action的检查，区分超管，否则根据acl进行匹配。使用acl 缓存，结合zk的linstener更新缓存。不管是否开启acl，都会去取acl缓存列表。 二、总结 kafka以事件、线程池的方式，对接口请求做处理。 每个api请求，都会做相关的acl校验，不管是否开启acl，都会去取acl缓存列表。差别在于是否使用acl cache map对action进行匹配，匹配本身是用遍历的方式，action不多的话，对吞吐的影响可以忽略不计。 网上有一篇性能测试：见这里
