レプリケーションと最終的な一貫性

レプリケーションと最終的な一貫性

1）なぜ最終的な一貫性

• 低い記録の遅れ（ローカル受信）、
• ネットワークパーティション中の可用性の向上、
• 水平スケーリング。

重要なタスクは制御された遅延の整合性です。ユーザーは「かなり新鮮な」データを見て、ドメイン不変量が保存され、競合が検出され、予測可能に解決されます。

2）一貫性モデル-私達が顧客に約束するもの

強い：読書はすぐに最後のエントリを見ます。
bounded stale/read-not-older-than （RNOT）： read not old than mark （LSN/version/time）。
因果関係：因果関係（A〜B）が維持される。
Read-Your-Writs：クライアントは彼の最近の録音を見ます。
Monotonic Reads：次のすべての読み取りは「ロールバック」ではありません。
セッション：1つのセッションの保証のセット。
Eventual：新しいエントリがない場合、すべてのレプリカが収束します。

練習：重要なパスでセッション+RNOTを結合し、ストアフロント/キャッシュでEventualを実行します。

3）レプリケーション： メカニクスとアンチエントロピー

同期（quorum/RAFT）：レコードはNノードによる確認後に成功したと見なされます。p99以上の最小RPO。
非同期：リーダーはローカルでコミットし、後でログを配布します。低遅延、RPO> 0。
物理（WAL/binlog）：高速、均質。
論理/CDC：行/イベントレベルの変更フロー、柔軟なルーティング、フィルタ。
アンチエントロピー：定期的な和解と修復（マークルツリー、ハッシュ比較、背景の再同期）。

4）バージョン識別子と因果順序

モノトーン版：increment/LSN/epoch；単純ですが並列性はエンコードしません。
Lamport timestamp：論理クロックによる部分順序。
ベクトルクロック：平行ブランチを修正し、競合する更新を検出することができます（並行）。
Hybrid/TrueTime/Clock-SI：グローバル注文のための「Not before T」ロジック。

推奨事項：CRDT/競合する更新-ベクトルクロック；for 「not older」-LSN/GTID。

5）競合： 発見と解決

典型的な状況：2つのリージョンから同じオブジェクトに記録します。

1.Last-Write-Wins （LWW） by hour/logical stamp-シンプルですが、更新が「失われる」可能性があります。

• カウンターフィールドが追加されます（G-Counter/PN-Counter）
• セットは"add-wins/remove-wins'、
• 金額/残高-トランザクションジャーナルを通じてのみ、単純なLWWを介してではありません。
• 3.CRDT（コンバージェントタイプ）：Gカウンター、OR-Set、 LWW-Register、リスト用RGA。
• 4.運用の変革（データベースではほとんどなく、エディタではより頻繁に）。
• 5.手動解像度：「受信トレイ」内の競合は、ユーザーが正しいバージョンを選択します。

ルール：ドメイン不変量は戦略を決定します。お金/バランスのために-LWWを避けてください。補償されたトランザクション/イベントを使用します。

6）保証およびidempotencyを記録して下さい

コマンドのIdempotentキー（支払い、引き出し、作成）→再試行は安全です。
idempotenceキー/シリアル番号による受信トレイと送信トレイの重複除外。
厳密に一度は強い前提なしで達成できません；少なくとも一度は+idempotencyを練習して下さい。
Outbox/Inboxパターン：データベースへの書き込みとイベントの公開は、idempotency-keyによる受信プロセスであるatomic （local transaction）です。

7）古いX読み取りなし（RNOT）

• LSN/GTIDゲート：クライアントは最小バージョン（書き込み応答から）を送信し、ルータ/プロキシはLSN ≥ Xに追いついたレプリカに送信します。それ以外の場合はリーダーに送信します。
• タイムバウンド：「2秒未満」-バージョンのないシンプルなSLA。
• セッションのピン留め：N秒を記録した後、リーダー（Read-Your-Writs）のみを読み取ります。

8）フローの変更とキャッシュネゴシエーション

CDC→イベントバス（Kafka/Pulsar）→消費者（キャッシュ、インデックス、店舗）

キャッシュ障害：トピック'invalidate： {ns}： {id}'；idempotent処理。
Rebuild/Backfill：同期しない場合は、イベントログから投影を再構成します。

9）サガと補償（サービス間取引）

• オーケストレーション：コーディネーターはステップとその補償を呼び出します。
• 振付：ステップはイベントに反応し、以下のものを公開します。

不変量（例）：「balance ≥ 0」-ステップ境界でチェック+偏差の補正。

10）複数の地域およびネットワークパーティション

Local-write、 async-replicate：ローカル領域への書き込み+他の（EC）への配信。
ジオフェンシング：データはリージョンに「接着」されます（遅延が少なく、競合が少ない）。
CPデータのクォーラムデータベース（Raft）；キャッシュ/ストアフロント-AP/EC。
Split-brainプラン：通信が失われた場合、領域はドメイン制限内で動作し続けます（フェンシング、クォータの書き込み）。

11）観察可能性およびSLO

• レプリカラグ：時間/LSN距離/オフセット（p50/p95/p99）。
• Staleness：しきい値を超える応答の割合（例：>2sまたはLSN
• 競合率：競合率とマージ成功率。
• 収束時間：ピーク後のレプリカの収束時間。
• バックログの調整：ラギングバッチのボリューム/時間。
• データカテゴリ（CP/AP）によるRPO/RTO。

• Lag> target、競合の増加、不可抗力の「長い」ウィンドウ。

12） ECデータスキーム設計

各エントリの明示的なバージョン/ベクトル（列'version'、 'vc'）。
critical invariants （balances、 accruals）のための追加専用ログ。
注文と重複除外のイベント識別子（snowflake/ULID）。
可換フィールド（カウンタ、セット）→CRDT候補。
API設計：if-match/etagでPUT、前提条件でPATCH。

13）貯蔵および読書パターン

Read model/CQRS： 「source」への書き込み、投影からの読み込み（→「updated」……の表示に遅れが生じる可能性があります）。
Stale-OKルート（カタログ/テープ）vs Strict（ウォレット/リミット）。
リクエスト内のSticky/Bounded-staleフラグ（ヘッダ'x-read-consistency'）。

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

0-10日

データの分類：CPクリティカル（お金、注文）対EU/steel-OK（カタログ、検索インデックス）。
Steele SLOの定義（例：「2s未満」）、ターゲットのlags。
APIでオブジェクトのバージョン管理とidempotency-keysを有効にします。

11-25日

CDCとoutbox/inbox、キャッシュ障害ルートを実装します。
書き込みクリティカルパスにRNOT （LSNゲート）とセッションピンを追加します。
少なくとも1つのマージ戦略（LWW/CRDT/ドメイン）と競合ログを実装します。

26-45日

アンチエントロピー（和解/修復）とスタイリングレポートを自動化します。
ゲームの日を過ごす：ネットワーク分離、紛争の急増、回復。
ダッシュボードで可視化：遅延、延滞、競合率、収束。

15）アンチパターン

クリティカル不変量のためのブラインドLWW（お金/ポイントの損失）。
再トレーニング中のidempotency→重複操作の欠如。
全体の「強い」モデル→失敗の場合の過剰なp99尾と脆弱性。
RNOT/セッション保証はありません→UXは「点滅」、ユーザーは「表示されません」彼らの変更。
隠しキャッシュとソースのずれ（CDC/disabilityなし）。
和解/アンチエントロピーツールの欠如-データは「何世紀にもわたって」分岐します。

16）成熟度の指標

レプリカラグp95 ≤ターゲット（たとえば、1つのリージョン内で500ミリ秒を≤、 2秒間のリージョンを≤）。
Staleness SLOは「厳密な」ルート≥要求の99％で実行されます。
紛争解決の成功≥ 99。9％、平均解像度の時間≤ 1分。
ピーク後の収束時間-分、時間ではありません。
「お金」トランザクションの100％は、idempotencyキーとoutbox/inboxによってカバーされます。

17）レシピ（スニペット）

If-Match/ETag （HTTP）

PUT /profile/42
If-Match: "v17"
Body: { "email": "new@example.com" }

バージョンが変更された場合-'412 Precondition Failed'→クライアントは競合を解決します。

クエリ「LSNより古い」（擬似）

x-min-lsn: 16/B373F8D8

ルータは'replay_lsn ≥ x-min-lsn'でレプリカを選択します。そうでなければリーダーです。

CRDT Gカウンター（アイデア）

各地域は独自のカウンターを保持します。Total-すべてのコンポーネントの合計Replication-Operationは可換です。

18）結論

最終的な一貫性は品質の妥協ではなく、意識的な契約です。どこかでスピードと可用性のために新鮮さを支払いますが、ドメイン戦略とツールで重要な不変量を保護します。バージョン、idempotency、 RNOT/Session保証、CDCおよびアンチエントロピーを入力し、遅延/失効/競合を測定します。分散システムは、グリッチとピーク負荷の下でも高速で安定かつ予測可能に収束します。