メッセージブローカー

1）なぜメッセージブローカー

• ピークバッファリングとスムージング、バックプレッシャー。
• 読み取り/書き込みスケーリングは独立しています。
• イベントの観察と再生。
• 建築パターン：イベント駆動、CQRS、イベントソーシング、アウトボックス/受信トレイ。

2）基本的なモデルおよび言葉

2.1カフカ（ログモデル）

トピック→パーティー（注文ログ）→消費者からのオフセット。
消費者グループ：並列性、パーティバランシングを読んでください。
時間/量による保持；キーの圧縮。
セマンティクス：最小-最低1回、設定-正確に1回（idempotent producers+transactions）。
順序：党の内で保証される。

2.2 NATS（被験者、低遅延）

階層とワイルドカード（'foo。'、'foo。>`).

モード：pub/sub、 queue-groups （fan-out with work distribution）、 request-reply （fast RPC）。
コアNATS-一時的で超低遅延；JetStream-持続/保持/繰り返し。
順序：最もよい努力、強い全体的な保証無し；JetStreamで-ストリーム上での順序、しかし、失敗の場合にはまれな順序変更が可能です。

3）配達意味論と一貫性

Idempotenceとdedupは、Kafkaの「正確に一度」であっても、アプリケーション/傷の責任です。

4）順序、仕切りおよびキー

カフカ（Kafka

メッセージキーを選択すると、パーティー→強いローカルオーダーが決まります。
Ключи： 'aggregate_id'、 'tenant_id'、 'order_id'。ホットキーは避けてください。
バランス：Nパーティー≈読み取り並列性レベル。

NATS

Coreでは、キュー・グループがバランスを行います。
JetStreamストリームは被験者によってシャッフルされます。低遅延で広範なファン/ファンに重点を置いています。

5）保持、再生および圧縮

カフカ（Kafka）

保持：'保持。ms/bytes'。
Compaction： 「last value by key」を格納します（スナップショット/キャッシュ/サガに適しています）。
リプレイ：どのコンサマーでもオフセットを「巻き戻す」ことができます。

ジェットストリーム

ストリーム：ファイル/メモのバックエンド、時間/バイト/メッセージ数によるストレージポリシー。
消費者：プル/プッシュ、耐久性/一時的な、件名接頭辞によるフィルター。
リプレイ：最初/オフセットのような（シーケンス）からの再納品または読み取り。

6）トランザクション、アウトボックス、一貫性

カフカ（Kafka

Idempotent Producer （'enable。idempotence=true'）：重複に対する保護。
トランザクション：複数のバッチの原子記録+コンシューマーオフセットのコミット→「穴」のない読み取りプロセス書き込みパターン。
Transactional Outbox： 1つのデータベーストランザクションにおけるビジネスイベントとアウトボックスラインの記録。

NATS

カフカのような「クロスストリーム」トランザクションはありません。outbox/inboxとidempotentの消費者（キー、デッドストア）を使用します。

7） RPCおよび要求応答

KafkaはRPCに不便です（高いオーバーヘッド、順序/答えはより困難です）。非同期コマンド/イベントを使用します。
NATS：リクエスト応答（ミリ秒、相関、タイムアウト）に最適です。

go resp, err:= nc. Request("profile. get", []byte(`{"id":42}`), 200time. Millisecond)

8）操作およびトポロジー

8.1カフカ

クラスター：ブローカー+ZooKeeper（旧バージョン以前）またはKRaft（新しいメタデータ）。

レプリケーション： Zone RF ≥ 3、 ISR/コントローラ

複数の領域：MirrorMaker 2/Clusterリンク；競合ポリシーを持つasset-liability/asset-asset。
ディスク/ネットワーク容量：'throughput × retention × replicas'から読み込みます。

8.2 NATS

クラスタ：多数のノード、スーパークラスタ（ジオディストリビューション）、周辺機器/エッジ用のリーフノード。

JetStream： ノードセットによるストリームの配置（配置）、レプリケーション（R=1。5).

WAN：予測可能な低遅延、簡単なフェデレーション。

9）安全性

カフカ（Kafka）

TLS （mTLS）、 SASL： SCRAM、 OAuthBearer。
トピック/グループ/トランザクションに関するACL。
暗号化「at rest」 （OS/ディスク）+ネットワークポリシー。

NATS

nkey/JWT ID、オペレータアカウント、サブジェクトごとのACL。
ノードとクライアント間のmTLS。
テナントの分離（アカウント）+限度。

10）観測可能性とパフォーマンス指標

カフカ（Kafka）

BytesIn/Out、 RequestQueue、 UnderReplicatedPartitions、 GC/FS stats。
トピック/パート：'logEndOffset'、コンシューマラグ（クリティカル）。
プロデューサー/コンサマー：retrai、 'batch。size'、'linger。ms'、'fetch。min。 bytes'、エラー。
ツール：JMX、クルーズコントロール（再バランス）、スキーマレジストリ。

NATS/JetStream

サーバー：conn/msgs/sec、 RTT、 CPU/memの遅い消費者検出。
JetStream：ストリームごと/消費者-遅延、再配達、acks、ストレージバイト。
モニタリング：内蔵エンドポイント、nsc/adm-CLI、ダッシュボード。

11）パフォーマンスとチューニング

カフカ（Kafka）

ビッグバッチと'残ります。ms 'improveスループットと圧縮p99。
圧縮（lz4/zstd）は、ネットワーク/ディスクを保存します。
数値。消費者/コアの数によるパーティション、しかし、オーバーヘッドしないでください。
ドライブ：NVMeが優先され、'noatime'とXFS/EXT4されます。

NATS

小さなメッセージ、多くの接続が標準です。キュー・グループを「wide」に保ちます。
JetStream： 'max_ack_pending'、プッシュとプル、バッチのサイズを調整します。
Backpressure： 'FlowControl'、' IdleHeartbeat'、サーバー側の制限。

12）統合パターン

Outbox/Inbox （KafkaとNATSの両方で）。
SAGA：イベントオーケストレーション；「saga_id+step」によって祖父。
変更データキャプチャ（CDC）： Debezium→Kafka；in NATS-「データベースのトリガー/ログからのパブリッシャー」パターン。
ストリーム処理：カフカストリーム/フリンク/スパーク；NATS-サードパーティのプロセッサ/機能、JetStreamの消費者。
デッドレターキュー（DLQ）とリトリーポリシー（指数バックオフ+ジッタ）。

13）構成例

13.1カフカ：トピックとプロデューサーを作る

bash kafka-topics. sh --create --topic orders \
--partitions 12 --replication-factor 3 \
--config cleanup. policy=delete \
--config retention. ms=604800000 # 7d

properties producer. properties bootstrap. servers=broker:9092 acks=all enable. idempotence=true batch. size=65536 linger. ms=10 compression. type=zstd

13.2カフカストリーム：idempotent machining（スケッチ）

java builder. <String, Order>stream("orders")
.groupByKey()
.aggregate(/... /)
.toStream()
.to("orders-agg");

13.3 NATS JetStream： stream+consumer （nats CLI）

bash nats stream add ORDERS --subjects "orders. " --retention limits \
--storage file --max-bytes 100GB --replicas 3 --discard old

nats consumer add ORDERS ORDERS-WORKERS --filter "orders. created" \
--deliver pull --ack explicit --max-deliver 6 --backoff "1s,5s,30s,2m"

13.4 NATSリクエスト返信（Go）

go nc, _:= nats. Connect("tls://nats:4222", nats. Secure(tlsConf))
sub, _:= nc. QueueSubscribe("calc. sum", "workers", func(m nats. Msg) {
//... process...
m. Respond([]byte("42"))
})

14）カフカ対NATSピック： クイックガイド

リプレイ、長期保存、圧縮、重いストリームプロセス→Kafkaが必要です。
高速RPC、ファンアウト/ファンイン、マイクロラテンシー、シンプルな操作、エッジ/IoT→NATS（コア）が必要です。
永続性+ファンアウトが必要ですが、重い「ログ」プラットフォームがない→NATS JetStream。
厳密なキーとトランザクションの順序→Kafka。

15）容量計画（簡略化）

カフカ（Kafka）

1.スループット：'inbound_MBps × RF × retention_days × 86400'→ディスク。
2.バッチ：'target_concurrency' ×在庫1。5-2 ×。
3.ネットワーク：p99+replication+producer圧縮。

NATS/JetStream

1.メッセージ/秒と平均→スループット。
2.保存×レプリカ→ストレージ。
3.消費者の制限（ack-pending、 redeliveries）、シリアル化のためのCPU。

16）安全な操作： チェックリスト

• TLS/mTLSが有効になり、シークレットが回転します。
• ACL/accounts/quotas（テナントごと）。
• 消費者、DLQ、およびジッタ後退に対するIdempotency。
• 遅延/スループット/エラー監視；URP （Kafka）、再配達嵐（NATS）に関するアラート。
• 容量ダッシュボード：パーティション、ストレージ、p99。
• ノード/ゾーン障害テスト、ゲーム日、リプレイ/バックフィル。
• スキーマレジストリ/JSONスキーマキーがドキュメント化されています。
• 保持/圧縮/TTLポリシーはコンプライアンスに準拠しています。
• ブローカー/クライアントのバージョンは定期的に更新されます。ワイヤプロトコルの互換性を確認しました。

17）アンチパターン

ホットキー（同じIDのすべてのイベント）→1つの「沸騰」ストリーム。シャーディ/バッファ。
idempotency→double効果なしで後退します。
巨大なメッセージ（MB-tens）→GC断片化/一時停止。ペイロードをオブジェクトに保存し、リンクを送信します。
カフカでRPCとストリーミングを混合→複雑なライフサイクル/順序。
「長期DWH」→オフラベルとしてJetStream；object/columnのベッドで長い間貯えて下さい。
No DLQ→「毒」メッセージが無限に回転します。
保持を忘れた→ディスクがいっぱい、クラスタストップ。

18） FAQ

Q：パイプラインの最後に「一度だけ」することはできますか？
A：実際には-効果的にはい：Kafka （idempotent producer+transactions）とidempotent sinks （key、 upsert）。NATSでは、アプリケーションのidempotence/dedupを使用します。

Q：百万の小さいRPCs/secのために選ぶべき何か？
A： NATS Core： Microlatency、 request-reply、 light connections、 queue-groups。

Q：財産の圧縮とスナップショットが必要ですか？
A：カフカのクリーンアップ。policy=compact'、key=aggregate/resource。

Q：遅れを取扱う方法か？
A：バッチ/ワーカーの数を増やし、処理時間を短縮し、バッチとプリフェッチを削減し、デシリアライゼーションを最適化し、ブローカー/ドライブを垂直に強化します。

Q：複数の地域およびDRか？
A： Kafka-MirrorMaker 2/Clusterリンク、RPO≈sekundyとの資産責任。NATS-スーパークラスター/リーフノード；ゾーン別のJetStreamミラーリング/レプリカ。

19）合計

KafkaとNATSはさまざまなモードを閉じます：Kafka-耐久性のあるイベントログ、高スループット、トランザクション性、リプレイ。NATSは低遅延、RPC、シンプルなファンアウト用の超軽量バスで、JetStreamは持続性を備えています。納品セマンティクス、注文と保持、レイテンシ、運用コストから選択してください。設計キー/パーティー、保持、DLQおよびオブザビリティ-およびイベントアーキテクチャは予測可能でスケーラブルで信頼性が高くなります。