Kafka と Redis のそれぞれの利点と欠点をご存知ですか?この記事はあなたの選択を最適化するのに役立ちます

序文

ビッグデータ技術は互いに補完し合います。欠点のない技術は存在せず、孤立して発展することもできません。今日は、分散パブリッシングとサブスクリプションの長所と短所を確認するために、Kafka と Redis の比較を分析します。

Redisとは

Redis はオープンソースで無料であり、BSD プロトコルに準拠しており、高性能なキー値非リレーショナル データベースです。ストレージ データベースとしての Redis は、分散パブリッシュ/サブスクライブ メッセージング システムである Kafka とどう違うのかと尋ねる友人もいるかもしれません。両者は同じレベルではありません。

ただし、Redis にはキュー データ型があり、これはパブリッシュ/サブスクライブ システムで使用され、Kafka と比較できます。

カフカとは何か

Kafka は、高スループット、分散型の、パブリッシュ/サブスクライブ ベースのメッセージング システムです。 Kafka テクノロジーを使用すると、安価な PC サーバー上に大規模なメッセージング システムを構築できます。 Kafka には、メッセージの永続性、高スループット、分散、マルチクライアントのサポート、リアルタイムなどの機能があります。

さて、乾いた品物です。KafkaとRedisの違いです。

さまざまなストレージメディア

Redis キュー データはメモリに保存されます。 AOF と RDB の永続化方法もありますが、メモリが依然として主な方法です。

Kafkaはハードディスクに保存されます

異なるパフォーマンス

ストレージ メディアが異なるため、理論的には Redis キューのパフォーマンスは Kafka よりも優れていますが、実際の使用では、このことはあまり明らかではありません。通常、Redis キューは、同時実行性の高いシナリオでのみ必要になります。たとえば、赤い封筒を送信する場合、赤い封筒を事前に分解してから Redis キューにプッシュすると、取得の瞬間に並行処理を適切にサポートできます。

異なるコスト

ここで、重要なポイントを強調する必要があります。重要なポイントを強調し、重要なポイントを強調します。

Kafka をハードディスクに保存するコストはメモリに保存するコストよりもはるかに低く、その差は 1 桁または 2 桁です。データ量が非常に多い場合、Kafka を使用するとサーバーコストを大幅に節約できます。最も一般的なログは、アプリケーションによって生成されるログです。これらのログの容量は一般に非常に大きくなります。処理する必要がある場合は、Kafka キューを使用できます。

これは、元のギャップについての簡単な紹介です。核となる比較を見てみましょう - メッセージキューの長所と短所

メッセージキューとしてのRedis

Redis のパブリッシュ (pub) およびサブスクライブ (sub) モード

Redis のパブリッシュ/サブスクライブ メカニズムは 3 つの部分で構成されます。パブリッシャー（プロデューサー）、チャネル（トピックに類似）、サブスクライバー（消費者）、具体的な構造は以下のとおりです。

Redis の pub-sub モデルは、西洋のファーストフード、ファーストフードと高速消費に非常に似ています。これはすべて、Redis がアクセスにメモリを使用するためです。生成したすべてのメッセージは、痕跡を残さずに消費者によって一度に処理されます。同時に、メモリは常に貴重なものであるため、メモリには制限があります。プロデューサーとコンシューマーが登場すると、Redis の効率も影響を受けます。さらに、Redis は、大容量 (10K 以上のファイル) のデータの公開と消費を処理する際に耐え難いほどの遅さを示します。

次のようなシナリオの場合は、Redisをメッセージキューとして使用することを検討してください。

• 需要が高速な生成と高速な消費を伴う即時消費シナリオであり、生成されたメッセージが消費者によって即座に消費される場合
• スピードが重要であれば、例えば1秒の遅れが数千万ドルの損失を意味する場合、
• メッセージの損失が許容される場合
• 送信したメッセージをシステムに保存する必要がない場合は、痕跡を残さずに退出できます。
• 処理するデータの量がそれほど大きくない場合

メッセージキューとしての KafKa

KafKa は、分割統治の考え方を使用して、分散型の高可用性デプロイメントをサポートし、大きなキューを複数のパーティションに分割して、キューに入るメッセージのスループットを向上させるように巧みに設計されています。また、消費時にグループの概念をサポートし、同じキューを消費する複数のクライアントをサポートできます。さらに、グループ内の消費者の数を増やすことで、消費処理能力を拡張できます。

KafKa は、安価なスタンドアロン サーバーでも 1 秒あたり 100,000 件のメッセージをサポートするのに十分なスループットを備えているため、プロデューサーの数の影響を受けません。消費者はいつでも好きなときに消費することができます。メッセージはそこにあり、非常に柔軟です。跡形もなく消えてしまうというパニックを心配する必要はありません。メッセージは、特定の戦略（一定期間内に削除する、または一定の容量に達したときにクリアするなど）に従って永続化および使用できます。

次のようなシナリオでは、KafKa をメッセージキューとして使用することを検討できます。

• 安定したメッセージキューが必要な場合
• 送信したメッセージを一定期間保存したい場合、メッセージは非表示にはなりません。
• データの損失に耐えられない場合
• スピードがそれほど速くなくても
• 膨大な量のデータを処理する必要がある場合

結論

Redis はキーのハッシュ方式を使用してデータを分散形式で保存します。 Redis をクラスターとして使用する場合、各アプリケーションは 1 つの Redis に対応するため、ある程度のデータの偏りが生じ、データ損失が発生します。

以前の Kafka クラスターのデプロイメントから、Kafka のトピックには複数のパーティション (コピー) を含めることができ、それらが Kafka クラスター上で均等に分散されるため、Redis のようなデータの偏りが回避されることがわかります。 Kafka には Redis の冗長性メカニズムも備わっています。 Redis クラスター内のマシンに障害が発生すると、データが失われる可能性があります。ただし、Kafka はクラスター ホストに均等に分散されているため、1 台のマシンに障害が発生しても、その使用には影響しません。同時に、サブスクリプション メッセージング システムとして、Kafka は 1 秒あたり数百万という高いスループット、永続性、分散性も備えています。