← 分散システム 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：論理時計（Lamportタイムスタンプ）　|　関連：線形化可能性と逐次一貫性・PACELC・結果整合性

要点（BLUF）

• 一貫性モデル＝複製システムが提供する「読み書きの見え方」の契約。強いほど直観的だが高コスト、弱いほど速く落ちにくいが異常を許す。
• 大きく2系統：データ中心（線形化可能性 → 逐次 → 因果 → 結果整合）と、クライアント中心（read-your-writes・monotonic-reads など、1ユーザ視点の保証）。
• 設計とは「このデータにどの契約が要るか」を選ぶこと。残高は強め、いいね数は弱めで十分、というようにデータ単位で決める。

問題設定 ── 強さを一直線に並べる

複製があると「最新が見えるか」が問題になります（レプリケーション方式（同期／非同期・リーダー／リーダーレス））。一貫性モデルは、許される/禁じられる読み書きの履歴を規定することで、この見え方を定義します。

地図 ── 強い順に並べる

flowchart TB
    L["線形化可能性（最も強い・実時刻順に1つの履歴）"] --> S["逐次一貫性（全員同一順・実時刻は不問）"]
    S --> CA["因果一貫性（因果のある操作だけ順序保証）"]
    CA --> E["結果整合性（いつかは収束・最弱）"]

仕組みの直観 ── 2つの軸

• データ中心：システム全体として履歴がどう揃うか（上表）。
• クライアント中心（セッション保証）：1ユーザの体感を守る軽い保証。
  • read-your-writes：自分の書き込みは自分には必ず見える（プロフィール編集直後など）。
  • monotonic-reads：一度新しい値を見たら、以後古い値に戻らない。
  • monotonic-writes / writes-follow-reads：自分の書き込み順や因果順を保つ。

弱いデータ中心モデルでも、クライアント中心保証を足すと「体感は十分まとも」にできます。これが結果整合データベースの実用の肝です。

正しさの観点 ── モデルは「禁じる履歴」で定義される

一貫性モデルの厳密な意味は「どんな読み書きの履歴を許し、どれを禁じるか」。線形化可能性は「実時刻順に矛盾しない唯一の直列化」が存在することを要求し（線形化可能性と逐次一貫性）、結果整合性は「最終的な収束」しか要求しません。強いモデルほど許す履歴が狭い＝守りやすいが作るのが高コスト。

他分野との比較 ── トランザクション分離レベルとの違い

DBの分離レベル（read committed・snapshot・serializable）は「複数オブジェクトをまたぐトランザクションの見え方」、一貫性モデルは「単一オブジェクトの複製の見え方」。直交する概念で、両方を組み合わせた最強が strict serializable（線形化可能 ＋ 直列化可能）。詳細は 分散トランザクションとSaga と データエンジニアリング へ。

なぜ分散だと難しいか（直観）

単一マシンのメモリは（ほぼ）線形化可能——書いたら次に読めば最新。複製すると、書き込みが全コピーに伝わるまで時間がかかり、その間に読むと古い値。強一貫を保つには毎回コピー間で合意が要り、遅く・落ちやすくなる（CAP定理・PACELC・結果整合性）。

⚠️ よくある誤解・落とし穴

• 「一貫性は高いほど良い」→ 高いほど遅く落ちやすい。データごとに必要十分を選ぶ。
• 「結果整合性＝壊れている」→ 収束は保証される。クライアント中心保証を足せば体感は良い。
• 「強一貫＝トランザクション直列化」→ 別概念。線形化は単一オブジェクトの実時刻順、直列化は複数オブジェクトのトランザクション順。
• 「因果一貫性があれば全順序も保証」→ 並行操作はばらつく。全順序が要るなら逐次以上。

対応ラボ

なし（概念回）。線形化違反の具体は 線形化可能性と逐次一貫性、可用性との取引は クォーラム（R+W>N） のラボで扱います。

関連

• 最強の契約の中身は 線形化可能性と逐次一貫性
• 分断時の選択は CAP定理
• 弱い側の実用は PACELC・結果整合性

← 第4章 一貫性モデル 目次