kafkaをメッセージブローカーとして使用して、デスクトップ/モバイル/ウェブアプリ用のリアルタイムプッシュ通知システムを作成する
Pub/subメッセージングパターンに従ってサーバーとクライアント間でリアルタイム通信が必要なユースケースがあります。プロデューサーはJavaのサーバー、ノードなどになり、クライアントは-Javaデスクトップアプリ、モバイルアプリ（Android/ios）、ブラウザー（javascript）になります。
以下で説明する多くのオプションを検討しましたが、強力でスケーラブルなソリューションを思い付くことができません。
ユースケース：サーバーはさまざまなトピックに関する通知/メッセージを公開し、一連のトピックにサブスクライブしているすべてのクライアント（Java/js/ios）はこれらのメッセージをリアルタイムで取得します。
私はこの問題を解決するために3つのアプローチに従いました1> socketIo/socketcluster 2> mosquitto/rabbitmqをブローカーとして使用してmqttプロトコルを調査しました。 3>カフカを探索
主な目標は、このアーキテクチャを高度にスケーラブルにし、100万を超える同時クライアント接続だけでなく、1秒あたりに発行および消費される100万を超えるメッセージを作成することです。
最初のアプローチは単純で機能しますが、webSocketはスケーラブルなソリューションではありません。
2番目のアプローチは機能しますが、rabbitmqは、接続されている各クライアントのキューを維持するため、多数のキュー（100万クライアントに対して100万キュー）を作成します。また、rabbitMqのメッセージの公開および消費率は高くありません。さらに、クラスターがあるとします。次に、rabbitMqノードのうち、1つのノードのみが要求の処理に使用され、他のノードは高可用性に使用されますが、並列消費には使用されません。
第三に、kafkaでクライアントを作成したベンチマークで知られる、Javaを探索しました。これは、Javaapiを使用してkafka kafka>] _トピックおよびこのトピックに公開されたメッセージは、リアルタイムでクライアントに配信されます。
だから私の質問は、リアルタイムのプッシュ通知にkafkaクライアントを使用するのがどれほど良いかということです。そこでは、すべてのJavaデスクトップアプリ（おそらく100万）にこれが含まれますkafka Java client sdkであり、特定のトピックにサブスクライブされます。ここでは、各クライアントをコンシューマーグループとして扱っています。
また、ここでの主な問題の1つは、このkafkaクライアントはscala依存関係のためにサイズが大きいため、Androidでこのクライアントを使用することは適切なオプションではないことです。また、私はそれがうまくいくとは思わない。
mqttは、Android、Java、iosなどの公式phaoクライアントを備えているため、ここで優れています。
また、100万人の消費者がいるpub/subメッセージングにkafkaを使用する例はウェブ上で見たことがありません。ほとんどの場合、リアルタイムログ処理、HDFSへのデータのフィード、分析エンジンなどのデータパイプラインに使用しています。 、ストリーム処理。
主な質問は、mqttプロトコル（Android/ios/web/iotでうまく機能する）をkafkaでメッセージブローカー（パブリッシュ/サブスクライブ率が高い）として使用するにはどうすればよいかということです。そして、この問題に対するスケーラブルなソリューションを考え出します。
私のユースケースは、何百万ものAndroid/iOSデバイス（クライアント）があり、地図上で私たちの場所にあるすべての車のリアルタイムの動きを実際に見ることができるuberに似ていますが、背後にあるアーキテクチャが何であるかを誰かが知っていますか？車のこれらのリアルタイム追跡。
この記事 Kafkaとnode.jsを使用してリアルタイムチャットシステムを作成する方法について説明します。また、例を含む git repo にもリンクしています。この記事から注意すべき重要な点は次のとおりです。
テストでは、メッセージを投稿してから他のすべてのクライアントに表示されるまでに約1秒の遅延があることに気付きました。これは、Kafkaがメッセージをディスクにコミットする頻度が原因であることがわかりました。 Kafkaはメッセージが失われないことを保証するため、メッセージをサブスクライバーに転送する前にディスクに書き出す必要があります。開発者は毎秒メッセージをディスクにフラッシュすることを選択しました。これは私たちが見た遅れを説明しています。
それは物事を行うための興味深い方法だと思いますが、それは仕事を成し遂げます。彼らが指摘しているように、焦点はレイテンシーではなくスループットにあるため、この種の使用法には理想的には適していませんが、仕事は完了します。