1.リクエストプロトコル形式
カフカは、相互作用のさまざまなを実現するために要求プロトコルのセットをカスタマイズしました。このようなメッセージを製造するための一般的なPRODUCE要求として、FETCH要求METADATA要求は、要求のためのカフカクラスタメタデータ情報で、消費者のニュースのためです。すべての要求は、TCPソケット方式を介してネットワークと通信しています。次のプロトコルの基本的な構造：
異なるAPI（PRODUCE、などをFETCH）、RequestBody ResponseBodyと構造的に異なります。
2.原子炉モード
反応器パターンは、特に同時複数のクライアントを処理するのに適したシナリオサーバに要求を送信し、一の実装のイベント駆動型アーキテクチャです。
下に示すように、原子炉パターンアーキテクチャ：
この図から、我々は、複数のクライアントが、原子炉への要求を送信見つけることができます。すなわち、図アクセプタにおける要求ディスパッチ・スレッドディスパッチャを有する反応器は、異なる作業要求のプロセスで複数のスレッドに送られます。
このアーキテクチャでは、単に、特定の論理処理を伴う非常に非常に軽量なので、高いスループット性能を持っていないディストリビューションを要求するためのアクセプタスレッド。これらのスレッドの仕事が任意に増加させることができるか、動的負荷容量を調整するために、実際の業務処理システムに基づいて減少しました。
3.カフカ要求処理モデル
反応器モデルに基づくカフカ要求処理モデル、次のように：
原子炉モードDispatcherに似たブローカーカフカの終わりがSocketServerコンポーネントが、それはまた、対応するアクセプタスレッドとワーカースレッドプールを持っていますが、カフカに、この作業は、ネットワークスレッドプールと呼ばれる、専用のスレッドプールの名前を持っています。カフカが提供ブローカエンドパラメータnum.network.threadsを、ネットワークのスレッドプール内のスレッドの数を調整します。そのデフォルト値は3で、ネットワークは、それは3つのスレッドは、クライアントから送信された要求に特化し、各ブローカーを開始しまし作成すると述べました。
Acceptor 线程采用轮询的方式将入站请求公平地发到所有网络线程中，因此，在实际使用过程中，这些线程通常都有相同的几率被分配到待处理请求。这种轮询策略编写简单，同时也避免了请求处理的倾斜，有利于实现较为公平的请求处理调度。
4. 请求处理
当网络线程拿到请求后，它不是自己处理，而是将请求放入到一个共享请求队列中。Broker 端还有个 IO 线程池，负责从该队列中取出请求，执行真正的处理。如果是 PRODUCE 生产请求，则将消息写入到底层的磁盘日志中；如果是 FETCH 请求，则从磁盘或页缓存中读取消息。如下图所示：
4.1 IO线程池
IO 线程池处中的线程才是执行请求逻辑的线程。Broker 端参数 num.io.threads 控制了这个线程池中的线程数。目前该参数默认值是 8，表示每台 Broker 启动后自动创建 8 个 IO 线程处理请求。
可以根据实际硬件条件设置此线程池的个数。比如，如果机器上 CPU 资源非常充裕，完全可以调大该参数，允许更多的并发请求被同时处理。
当 IO 线程处理完请求后，会将生成的响应发送到网络线程池的响应队列中，然后由对应的网络线程负责将 Response 返还给客户端。
4.2 请求队列和响应队列
请求队列是所有网络线程共享，而响应队列则是每个网络线程专属的。
这么设计的原因就在于，Dispatcher 只是用于请求分发而不负责响应回传，因此只能让每个网络线程自己发送 Response 给客户端，所以这些 Response 也就没必要放在一个公共的地方。
4.3 DelayedOperaionPurgatory组件
Purgatory 的组件，这是 Kafka 中著名的“炼狱”组件。它是用来缓存延时请求（Delayed Request）的。所谓延时请求，就是那些一时未满足条件不能立刻处理的请求。比如设置了 acks=all 的 PRODUCE 请求，一旦设置了 acks=all，那么该请求就必须等待 ISR 中所有副本都接收了消息后才能返回，此时处理该请求的 IO 线程就必须等待其他 Broker 的写入结果。当请求不能立刻处理时，它就会暂存在 Purgatory 中。稍后一旦满足了完成条件，IO 线程会继续处理该请求，并将 Response 放入对应网络线程的响应队列中。
