プロトコル (クラスタ) — サーバー ↔ サーバー ​

クラスタモードでのみ使われるピアRPCプロトコルです。ノードはRaftコンセンサスによって 1つのロック状態を共有します — すべてのロック状態変更(獲得・解放・失効)は、リーダーの 提案 → 過半数への複製 → コミットを経て初めて適用されるため、分断やフェイルオーバー中でも 排他制御が保たれます。概念的な説明は 動作原理を参照してください。

フロー — 1つの獲得がコミットされるまで ​

リーダーはロックコマンドを複製コマンドに変換し、 AppendEntriesのRPCに乗せて、自分自身を含む過半数が 記録した時点でコミットします(3ノードならリーダー+フォロワー1で十分で、残りは待ちません)。 クライアントへの応答はコミット後にのみ送出されるため、応答を受け取った時点でそのロックは 過半数に書き込まれています。

ポート・アドレスの規則 ​

• ピアRPCは専用のRaftポート = クライアントポート + 1000を使います(例: 5225 → 6225)。 別途の設定キーなしで自動的に導出され、クラスタモードでのみリッスンします。ファイア ウォールでは両方のポートを開く必要があります。
• 設定(cluster_self/cluster_peers)には常にクライアントアドレスが入ります。ピアへの 発信時のみポートに+1000が加わります — クライアントに渡されるM(移動)のリダイレクト アドレスは常にそのままのクライアントアドレスです。
• 役割はポートのみで区別されます — プロトコル内にクライアントとピアを区別する手順は ありません。接続の順序と認証/TLSのルールは 接続と認証を参照してください。

目次 ​

• サーバー間
  • 接続と認証
  • フレーム構造
  • RPCの種類
  • 複製コマンド
  • スナップショット
• Raftパラメータ
• 設定 (環境変数)
• 無停止再起動(ローリング)手順

関連ページ ​

• リーダー選出・過半数コミット・障害シナリオのわかりやすい説明 — 動作原理
• クライアントがリーダーを見つける方法 — M · 移動、 応答マッチングルール
• 実際のデプロイ構成(Docker、Kubernetesなど) — Ticketingサーバーデプロイ