分散データの正確性
契約から始める
不変条件、そのスコープ、そしてそれが耐えなければならない障害を書き留めます。「注文は最大1回請求される」は有用ですが、「強力な一貫性」では不十分です。信頼できるレコード、派生ビュー、アクター、および各コミット/確認応答の境界を特定します。クライアントが読み取り後の書き込み保証、因果順序、線形化可能な操作、直列化可能なトランザクション、または単なる最終的な収束を必要としているかどうかを問いかけます。
レビュー手順
- データベースコミット、ブローカーの確認応答、外部副作用を含む書き込みパスを描きます。各成功応答が、プロセスクラッシュ、マシン障害、またはレプリカフェイルオーバーの後に何を保証するかを記録します。タイムアウトは結果不明を意味し、必ずしも実行失敗ではありません。
- すべての永続的ステップの前後にあるクラッシュウィンドウを列挙します。それぞれについて、操作を再実行し、不変条件をチェックします。逐次再試行だけでなく、同時実行の試行もテストします。障害台帳を使用します。
- ビジネス効果とその重複排除マーカーは、同じデータベースを共有する場合は1つのトランザクションに保持します。送信イベントについては、トランザクショナルアウトボックスを検討します。リモート効果については、永続的なプロバイダのべき等性契約または調整ステートマシンを必要とします。ブローカーの配信保証は、文書化されたトランザクション境界で終了します。
- 順序付けのスコープ（キー、パーティション、ストリーム、またはグローバル）を特定します。不変条件を維持する最も狭いスコープを選択します。パーティション化されたログはパーティションを順序付けますが、異なるパーティションの関連イベントを自動的に順序付けするわけではありません。
- レプリケーションとフェイルオーバーについては、選挙、フェンシング、確認応答ポリシー、およびリカバリを検査します。
R + W > Nは固定メンバーシップの下で集合の共通部分を与えますが、それだけでは線形化可能性を確立しません。一貫性を参照してください。 - シャーディングについては、トランザクションの局所性、ホットキー、リバランシング、および一意性の強制を検証します。集約スループットだけでなく、最もビジーなシャードを測定します。
- 疑わしい保証に対する最小の反例と、それを実行するテストを生成します。必要な保証と許容可能な古さを区別します。
レビュー出力
次を返します：不変条件 → 前提条件 → 障害タイムライン → 違反された保証 → 最小限の修正 → コスト → 検証。既に矛盾したデータに対する回復パスを含めます。データベース、ブローカー、またはプロバイダのバージョンに依存する動作をすべて名前付けします。
推奨前の確認事項
- 再試行されたリクエストは、変更されたパラメータで安定した操作IDを再利用できますか？
- リースホルダーは、リソースによって強制される単調増加するフェンシングトークンを必要としますか？リースの期限切れだけでは、一時停止されたプロセスを停止できません。
- レプリカは、成功した書き込みの直後に古い値を提供できますか？
- トゥームストーンまたは重複排除レコードは、再生期間の前に期限切れになりますか？
- 複数レコードの不変条件は、トランザクションまたは明示的な調整を必要としますか？
スコープと参照
Designing Data-Intensive Applications、第2版（Kleppmann and Riccomini）に沿った部分的なカバレッジ。これらの元の手順は、公開された著者のコースノートと追加の一次ドキュメントを使用しています。完全な書籍は入手できませんでした。正確な帰属についてはソースを読んでください。このスキルは、合意実装を提供したり、ビザンチン障害耐性を前提としたりしません。