この章の内容

• 分散トランザクションが今のアプリケーションに向かないのはなぜか
• マイクロサービスアーキテクチャでデータの整合性を維持するための <Saga> パターン
• コレオグラフィとオーケストレーションを使ったサーガのコーディネート
• 分離性がないことに対する対策

知っておいた方良さそう

2PC

• two-phase comit
• いつもつかってる begin ... commit のこと

ACID

• 信頼性のあるトランザクションが持つべき 4 つの性質のこと
• MySQL もこの性質を持ってる
• A (atomic) - 原子性
  • トランザクションに含まれる一連の動作が全て一括で「完了する」または「全く行われない」こと
  • begin ... commit で括った insert や update は同時期に反映されるみたいなこと（rollbackも）
• C (Consistency) - 一貫性
  • トランザクションの開始と終了時の整合性を満たしていることを保証する性質
  • MySQL では機能的に「二重読み込みバッファー」「クラッシュリカバリー」という仕組みで一貫性を保っている
• I (Isoration) - 分離性
  • トランザクションの途中経過が分離されている（利用者からはトランザクション開始前と終了後の値のみ観測できる）こと
  • A, B, C のデータを更新するというトランザクションがあったとき「A だけが更新された状態」とはならないこと
  • 厳密な分離性の実現には「トランザクションが直列であること」が必要になるが、アプリケーション的に「分離性レベル」を定めてここについては緩やかになっていることが一般的（ golang とかだと *sql.Tx.BeginTx の第二引数から指定できるレベルがここ）
• D (Durability) - 永続性
  • トランザクション操作は永続的なものであり失われないことを保証
  • MySQL とかもここを保証するのに色々（雑）やってる

分散トランザクション

• XA という標準がある。MySQL も XA 準拠で XA ~ の構文で使える
• コミットを prepare フェーズ, commit フェーズに分けることで複数のシステムからのデータの更新を同期的に整合性を保ってできるようにする仕組み