メッセージキュー：RabbitMQ、 Kafka

メッセージキュー： RabbitMQ、 Kafka

1）いつ選ぶべきか

RabbitMQ （AMQP 0-9-1/1。0、クラシックキュー、Quorumキュー、ストリーム）

のために適した：RPC/コマンド、ワークフロー、短いタスク、ファンアウト/トピックのルーティング、柔軟な確認、優先順位制御。
長所：豊富なルーティングセマンティクス（取引所）、'basic。qos '（prefetch）、メッセージごとのTTL/delay、便利なRPC（返信先）パターン、容易な開始。
短所：キューに保存された履歴、キュー/シャード間で水平に拡大；非常に大きなフローで高スループットコスト。

Apache Kafka（イベントログ、パーティー、消費者グループ）

のために適した：イベントストリーム、監査、イベントソーシング、ETL/インテグレーション（接続）、高いRPS/MBps、リプレイ/再処理、ストリーム処理（ストリーム/ksqlDB）。
長所：長期ジャーナル、パーティーによるスケーリング、安定した再生、キー圧縮。
短所：プル+パーティモデル-小さなRPCではありません。パーティー内のみの注文。スキーマ管理/相互運用性はチームの責任です。

💡 練習：コマンド/タスク→RabbitMQ、 events/audit/ETL→Kafka。大きなシステムでは、両方が共存しています。

2）配信セマンティクスと不変量

At-once：リトレイなし；速く、損失の危険。
少なくとも一度：リトリートで；消費者のアイデンポテンシーが必要です。
正確に一度：限られた条件で達成可能（Kafka TX+idempotent producer+consistent sink；RabbitMQ-重複除外テーブル/idempotentキーを介して）。
注文：RabbitMQ-キュー注文（レトラ/マルチ消費者で違反する可能性があります）；カフカ-パーティーの順序、キーは、パーティションを設定します。

ドメイン不変量：お金/残高-雑誌/サガとidempotentチームを通じて；LWWに頼らないでください。

3）統合パターン

Outbox/InBox：データベース内のイベントの原子記録→キュー（outbox）への公開、処理ログ（inbox）によるidempotent消費。
DLQ（デッドレター）：N試行/エラーの後-DLQ+アラート。
再試行/遅延：RabbitMQ-TTL+デッドレター交換；Kafka-バックオフでトピックを再試行します。
リクエスト/返信：RabbitMQ-'reply_to'+'correlation_id'；カフカ-まれに、特別なパターンでのみ。
補償：イベント上のサガ；それぞれの操作には逆数があります。

4）キーおよびトポロジーの設計

RabbitMQ

取引所：'direct'、 'topic'、 'fanout'、 'headers'。
ルーティングキー：キューのヒットを指定します。優先順位付けのために-別のキュー。
QoS： 'prefetch'（例：50-300）レート/レイテンシのバランス。
Quorumキュー：Raft上のレプリケートされたキュー；取り替えは古典を映しました。
ストリーム：ハイスループット/リプレイのためのオフセット付きストリーム（Kafka風）。

カフカ

トピック→パーティション：ターゲットスループットと並列性に'#partitions'を計画します（下位互換性の増加は減少よりも簡単です）。
キー：1つのキーのすべての記録-1つの部分で（キーによる順序の保証）。

Replication factor： 3 for productive topics、 'min。 insync。replicas=信頼性のために2'+'acks=all'

保持：時間/サイズによって；compaction-最後の値をkey+tombstonesで保存して削除します。

5） Retrai、 DLQ、 idempotency

RabbitMQ

繰り返し：バックオフ付きメッセージごとのTTL+DLX（デッドレター交換）（例：1m→5m→15m）。
Idempotence： 'correlation_id'/'message-id'+processed message table （TTL）またはdeterministicコマンド。
確認：manual 'basic。成功したトランザクションの後のack；'基本的なことです。nack （requeue=false）'-DLQ。

カフカ

繰り返し：個々の再試行トピック；成功した副作用の後の消費者のコミットのオフセット。
正確に一度処理（EOS）： Producer 'enable。idempotence=true'、トランザクションプロデューサー/消費者、消費者に対する'read_committed'；シンク（たとえば、トランザクションを介してKafka→KafkaまたはKafka→DB）-きれいに同期します。
Dedup：ベース側のキー/idempotentキー、または圧縮されたトピックを使用します。

6）性能および次元

リトルの法則： 'L=λ × W'

vorkerの場合： 必要な重複'N 在庫（1。2–1.5)`.

RabbitMQ prefetch： 'prefetch=100'で開始し、p99/機内時間を測定します。
Kafkaパーティション：所望の消費者並列性とスループット目標からの計算（例えば、1バッチはSSD/10GbEで安定した5-20 MB/s）。

7）観察可能性および警報

General：

Lag/Backlog （messages/bytes）、 age of messages （p95/p99）、 error-rate of processing、 DLQ-rate。
時間「publikatsiya→obrabotka」（エンドツーエンド）。
依存関係マップ：producer→broker→consumer。

RabbitMQ：

接続、チャンネル、非ackedメッセージ、'memory_alarm'、 'disk_free_limit'、 'queue length' p95。
Quorumに関するレポート（リーダー、Raft log、 'quorum not enough'）。

カフカ：

レプリケートされていないパーティション、ISRの縮小/展開、コントローラの変更。
プロデューサーのエラー（タイムアウト、'リクエストの遅延'）、グループ/パーティションごとの消費者の遅延。
ブローカーI/O、ページキャッシュヒット、GC、 ZooKeeper/KRaft健康。

8）安全および複数のテナント

TLS in-transit暗号化、認証（SASL/PLAIN/SCRAM/OAuth、 mTLS）。
認可：vhost/permissions （RabbitMQ）、 ACL to topics/groups （Kafka）。
クォータ：接続、チャンネル、キューのサイズ/トピック、発行/読み取り速度。
環境（dev/stage/prod）と名前空間/vhostによる分離。

9）操作およびチューニング

RabbitMQ

ノードへの交換/キューのポスト（CPU/IOキャピタル）。
大きなバッファのための遅延キュー（ディスクへのメッセージ）；shardingなしで「熱い」キューを避けて下さい。
HAのクォーラムキュー；Raftログサイズとディスクを計画します。
TTL/length-limitポリシー、リアルニーズ（高価）のみの優先キュー。

DLQ/TTLポリシーの例（アイデア）：

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

カフカ

SSD/NVMeの速いネットワーク；OSチューニング（スワップ性が低い、ファイル制限）。
'acks=all'、 'linger。ms '（butching）、'圧縮。type=zstd '/lz4で帯域幅を指定します。
消費者オプション：'max。 poll。インターバル。ms'、'max。世論調査。レコード'、'fetch。min。 bytes'。
保存と圧縮-ストレージのバランス/再生。

信頼できるパブリッシングの例（Java、アイデア）：

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10）統合とエコシステム

Kafka Connect（シンク/ソース）、スキーマレジストリ（Avro/JSON/Protobuf）、相互運用性（'BACKWARD/FORWARD/FULL'）。
Kafka Streams/ksqlDB：ステートフルな操作、ウィンドウ、集計。
RabbitMQ Shovel/Federation：クラスター/センター間の転送。
K8s演算子：Strimzi （Kafka）、 RabbitMQクラスター演算子；GitOpsマニフェスト。

11）実装チェックリスト（0-45日）

0-10日

ユースケースを定義する：コマンド/タスク（RabbitMQ）、イベント/監査（Kafka）。
キー（'ルーティングキー'/'パーティションキー'）を選択し、SLOを「publikatsiya→obrabotka」に設定します。
基本的なセキュリティポリシー（TLS、 ACL）、クォータ、DLQ/TTL。

11-25日

outbox/inbox、 idempotency、 deadupを実装します。
バックオフでリトリアを設定します（ウサギ：TTL+DLX；Kafka： retry topics）。
ダッシュボード：遅延、年齢、DLQレート、エンドツーエンドのレイテンシ；警告します。

26-45日

チューニング帯域幅： prefetch/acks （Rabbit）；パーティション/acks/batch （Kafka）

DRプロシージャ（ミラーリング/レプリケーション）、ノード障害テスト。
イベントコントラクト（スキーマ）と相互運用性ポリシーを文書化します。

12）アンチパターン

すべてのタスクのための1つの「ユニバーサル」ツール。
DLQ/TTLの不在：永遠の毒（毒メッセージ）。
無制限の'prefetch'→消費者飢餓、p99成長。
キーのないカフカ→デフォルトで注文/ホットパーティーの損失。
真の必要性/規律を持たない「正確に一度」は、誤った安心感です。
TLS/ACLなしで、コード内の秘密/ログイン。
レジストリとマイグレーションなしのメッセージのスキーム/バージョンのハードコード。

13）成熟度の指標

遅延/年齢SLOは、時間の99％ ≥実行されます。制御されているDLQ率。
Idempotencyは重要な経路の100％をカバーします。outbox/inboxを実装しました。
保持/圧縮は文書化され、リプレイは消費者を壊すことはありません。
ISR/URP （Kafka）とRaft/Disk Limits （Rabbit）のアラートが設定されています。
イベント契約はバージョン管理（スキーマレジストリ）され、互換性はCIでテストされます。
通常のゲーム日：ノード/ブローカー/AZ障害、リカバリチェック。

14）構成例（要約）

RabbitMQ：接頭辞と確認（擬似コード）：

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

カフカ消費者（アイデア）：

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15）結論

RabbitMQとKafkaは、コマンド/タスク、長期イベントログに対する豊富なルーティング、スケーラブルなストリーミングなど、さまざまな問題を解決します。成功-正しい配信セマンティクス、アイデンポテンスの規律、思慮深いキーイング、リトレイ/DLQ、観測性と厳格なセキュリティ。アウトボックス/受信トレイ、スキーマ、GitOpsポリシーなどのキューに関するエンジニアリング・プラクティスを構築することで、統合は予測可能、拡張可能、持続可能になります。

メッセージキュー：RabbitMQ、 Kafka

Apache Kafka（イベントログ、パーティー、消費者グループ）

カフカ

カフカ

カフカ

11-25日

26-45日

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です