1.爬虫代码不再赘述，见gitlub, 源码之中，了无秘密，基于原型demo 创建的爬虫的源码。

2.kafka 源码分析：

一、Kafka消费者源码介绍

1.分区消费模式源码介绍

分区消费模式直接由客户端(任何高级语言编写)使用Kafka提供的协议向服务器发送RPC请求获取数据，服务器接受到客户端的RPC请求后，将数据构造成RPC响应，返回给客户端，客户端解析相应的RPC响应获取数据。
Kafka支持的协议众多，使用比较重要的有：
获取消息的FetchRequest和FetchResponse
获取offset的OffsetRequest和OffsetResponse
提交offset的OffsetCommitRequest和OffsetCommitResponse
获取Metadata的Metadata Request和Metadata Response
生产消息的ProducerRequest和ProducerResponse

2.组消费模式源码介绍

 

3.两种消费模式服务器端源码对比

分区消费模式具有以下特点：
指定消费topic、partition和offset通过向服务器发送RPC请求进行消费;
需要自己提交offset；
需要自己处理各种错误，如:leader切换错误
需要自己处理消费者负载均衡策略
组消费模式具有以下特点：
最终也是通过向服务器发送RPC请求完成的(和分区消费模式一样);
组消费模式由Kafka服务器端处理各种错误，然后将消息放入队列再封装为迭代器(队列为FetchedDataChunk对象) ，客户端只需在迭代器上迭代取出消息；
由Kafka服务器端周期性的通过scheduler提交当前消费的offset，无需客户端负责

 

Kafka服务器端处理消费者负载均衡
监控工具Kafka Offset Monitor 和Kafka Manager 均是基于组消费模式；

所以，尽可能使用组消费模式，除非你需要：
自己管理offset(比如为了实现消息投递的其他语义);
自己处理各种错误(根据自己业务的需求)；

二、Kafka生产者源码介绍

1.同步发送模式源码介绍

 

2.异步发送模式源码介绍

 

3.两种生产模式服务器端源码对比

同步发送模式具有以下特点：
同步的向服务器发送RPC请求进行生产;
发送错误可以重试；
可以向客户端发送ack;
异步发送模式具有以下特点：
最终也是通过向服务器发送RPC请求完成的(和同步发送模式一样);
异步发送模式先将一定量消息放入队列中，待达到一定数量后再一起发送；
异步发送模式不支持发送ack，但是Client可以调用回调函数获取发送结果；

所以，性能比较高的场景使用异步发送，准确性要求高的场景使用同步发送

三、Kafka Server Reactor设计模型

1.认识Java NIO

Java NIO由以下几个核心部分组成 :
Channels;
Buffers；
Selectors

Selector允许单线程处理多个 Channel。使用Selector，首先得向Selector注册Channel，然后调用它的select()方法。此方法会一直阻塞到某个注册的Channel有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子如新连接进来，数据接收等。

下图为一个单线程中使用一个Selector处理3个Channel：

 

 

2.认识Linux epoll模型

epoll 是一种IO多路复用技术 ，在linux内核中广泛使用。常见的三种IO多路复用技术为select模型、poll模型和epoll模型。
select 模型需要轮询所有的套接字查看是否有事件发生 。缺点: (1)套接字最大支持1024个；(2)主动轮询效率很低；(3) 事件发生后需要将套接字从内核空间拷贝到用户空间，效率低
poll模型和select模型原理一样，但是修正了select模型最大套接字限制的缺点；
epoll模型修改主动轮询为被动通知，当有事件发生时，被动接收通知。所以epoll模型注册套接字后，主程序可以做其他事情，当事件发生时，接收到通知后再去处理。修正了select模型的三个缺点(第三点使用共享内存修正)。
Java NIO的Selector模型底层使用的就是epoll IO多路复用模型

3.Kafka Server Reactor模型

Kafka SocketServer是基于Java NIO开发的，采用了Reactor的模式(已被大量实践证明非常高效，在Netty和Mina中广泛使用)。Kafka Reactor的模式包含三种角色：
Acceptor;
Processor ；
Handler；
Kafka Reacator包含了1个Acceptor负责接受客户端请求，N个Processor线程负责读写数据(为每个Connection创建出一个Processor去单独处理,每个Processor中均引用独立的Selector)，M个Handler来处理业务逻辑。在Acceptor和Processor，Processor和Handler之间都有队列来缓冲请求。

Acceptor的主要职责是监听客户端的连接请求，并建立和客户端的数据传输通道，然后为这个客户端指定一个Processor，它的工作就到此结束，这样它就可以去响应下一个客户端的连接请求了;
Processor的主要职责是负责从客户端读取数据和将响应返回给客户端，它本身不处理具体的业务逻辑，每个Processor都有一个Selector，用来监听多个客户端，因此可以非阻塞地处理多个客户端的读写请求，Processor将数据放入RequestChannel的RequestQueue 中和从ResponseQueue读取响应 ；
Handler(kafka.server.KafkaRequestHandler,kafka.server.KafkaApis)的职责是从RequestChannel中的RequestQueue取出Request，处理以后再将Response添加到RequestChannel中的ResponseQueue中；