NATS

単一の Go バイナリとして配布される高性能メッセージングシステム。fire-and-forget な中核の上に、JetStream による永続化を任意で追加できる。

カテゴリ: Messaging & Streaming
CNCF 成熟度: Incubating
言語: Go
ライセンス: Apache-2.0
リポジトリ: nats-io/nats-server
ドキュメント基準コミット: bd058fac (default ブランチ HEAD、ソース VERSION は 2.15.0-dev、直近リリースは v2.14.2)

何をするものか

NATS は publish/subscribe 型のメッセージングシステム。送信側は subject (orders.eu.new のようなドット区切り文字列) にメッセージを送り、サーバはその subject にマッチする interest を持つすべての購読者へ配送する。マッチングは subject トークンの木とワイルドカードで行うため、購読側は orders.*.new や orders.> といったパターンで interest を表現できる。

中核プロトコルは at-most-once。サーバはディスクに何も保持せず、購読者が現在いないメッセージは破棄される。この中核の上に JetStream が永続化・リプレイ・at-least-once 配送・key/value バケット・オブジェクトストレージを追加する。JetStream はデータを独自の追記型ファイル形式で保存し、クラスタ間を Raft で複製するため、外部 DB を必要としない。

単一の nats-server バイナリが配置形態の全レンジをカバーする。スタンドアロンプロセス、ルーティングされたサーバ群によるクラスタ、リージョン横断のゲートウェイによるスーパークラスタ、クラスタをエッジまで延ばす leaf node まで。同じ接続処理コードが、各接続に kind を付けることでこれらすべてを担う (server/client.go:259)。

いつ使うか

サービス間の request/reply や pub/sub で低い tail latency が欲しく、それを 1 バイナリ・外部依存なしで実現したい。
リージョン横断やエッジデバイスへの展開があり、後付けではなく組み込みのトポロジ (ゲートウェイ、leaf node) が欲しい。
at-least-once 配送・リプレイ・key/value ストアが必要で、それを同じシステムから JetStream 経由で得たい。
Kafka 流のパーティション/オフセット意味論を第一級モデルとして求める場合は適合度が下がる。厳密な per-key 順序と水平スケールの両立は、subject ベースのパーティショニングを自分で組むことになる。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとリクエストの流れ。
採用事例・エコシステム: 誰が動かし、周囲に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動く構成。

NATS ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

NATS

何をするものか

いつ使うか

このディープダイブの構成

出典