# Apache Kafka LinkedIn で開発され、当初はログ処理に使われた分散メッセージブローカ。Kreps・Narkhede・Rao らによる NetDB 2011 論文が原典(Kafka: A distributed messaging system for log processing)。**信頼性をスループットでトレードオフ**する設計選択を取り、高スループット・低レイテンシのメッセージキューを提供する。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]]) ## アーキテクチャ(2017 時点) - データを **topic** に分割、topic を **partition** に分割し各 broker は 1 つ以上の partition を保持。consumer は **pull モデル**で自ペースで読む。 - ストレージは partition の segment 列、メッセージは**論理オフセット**で識別、broker レベルキャッシュなしで **OS ページキャッシュ**に完全依存(write-through + read-ahead)。 - consumer group が論理的に 1 consumer として動き、partition がパラレリズムの最小単位、leader/master ノード概念なし。**Zookeeper** を合意サービスとして Broker/Consumer/Ownership/Offset の 4 種レジストリで状態管理。 - 配送保証は **at-least-once**、exactly-once は 2PC が必要で「やりすぎ」と判断しデデュプは応用層に委譲。partition 内は単調増加オフセットで順序保証、メッセージ単位 CRC で破損検出。 ## スループット優位の根拠(John+ 2017 §6) 1. **SendFile API** でカーネルバッファをバイパス、file channel → socket 直書き。 2. シーケンシャルディスク書き込み + OS ページキャッシュ。 3. 標準で利用可能なバッチング。 ## ベンチマーク(John+ 2017 §5) 5 ノード(12 コア・16GB・1Gbps HDD)で Flotilla 計測: - single P/C スケールアウト: payload 一定でノード追加するとレイテンシ 3 倍改善、スループット 1.06 倍低下(ほぼ維持)。 - multi P/C 同一ノード: producer/consumer 5 倍でレイテンシ 100 倍悪化、consumer スループット 29 倍低下。Zookeeper が単一ノード上で resource contention の焦点となり context switching が増えるため、と論文は説明。 ## 関連 - ソース: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] - 概念: [[分散メッセージブローカ]] - 比較対象: [[AMQP]]、[[RabbitMQ]]