分散システムにおける一貫性モデル

[[413697]]

最近、分散システムにおける強力な一貫性モデルに関する素晴らしいブログを見ました。共有しない理由は本当にありません。最近かなり時間が空いたので、一つはじっくり読むため、もう一つはもっと親しみやすい形で共有するため、翻訳してみることにしました。ランダムに個人的な追加がいくつか挿入され、コメントセクションの素晴らしい議論も選択的に翻訳されます。オリジナル記事はこちら: https://aphyr.com/posts/313-st ... odels

ネットワークパーティションが発生する可能性があります。スイッチ、ネットワーク インターフェイス コントローラー (NIC)、ホスト ハードウェア、オペレーティング システム、ハード ディスク、仮想マシン、言語ランタイム、そしてプログラム セマンティクス自体も、メッセージの遅延、ドロップ、重複、または順序変更の原因となります。不確実性に満ちた世界では、プログラムが直感的な正しさの感覚を維持することが求められます。

はい、直感的な正確さを求めています。それなら正しいことをしてください！しかし、何をするのが正しいのでしょうか?どのように説明すればいいでしょうか?この記事では、いくつかの「強力な」一貫性モデルを見て、それらがどのように相互に適合するかを確認します。

正確さ

アルゴリズムの抽象的な動作を記述する方法は多数ありますが、一貫性を保つために、システムは状態と状態遷移を引き起こすいくつかの操作で構成されていると言います。システムが実行されると、操作が進化するにつれて、システムはある状態から別の状態に移行します。

ユニプロセッサの歴史

たとえば、状態は変数であり、操作はこの変数の読み取りと書き込みになります。この単純な Ruby プログラムでは、変数を複数回読み書きし、書き込みを出力の形式で表します。

 }) ; x を置きます。 xを置く
}) ; xを置く
x = "c"
 x = "d" ; xを置く

プログラムの正しさについては、すでに直感的な概念があります。上記のプログラムは“aabd”を出力するはずです。なぜ？なぜなら、それらは順番に起こるからです。まず写入值a 、次に读到值a 、次に读到值a 、写入值b 、というように繰り返します。

変数に何らかの値、たとえばa書き込むと、変数が再度変更されるまで読み取り操作はa返す必要があります。読み取られた値は常に最後に書き込まれた値を返す必要があります。このシステムを、 - 単一値変数 - 単一レジスタ（ハードウェア レベルのレジスタではなく、 act like a registerレジスタ）と呼びます。

私たちはプログラミングの初日からこのモデルを学び、それが私たちにとって第二の性質になりますが、これが変数が機能する唯一の方法ではありません。変数は、 a 、 d 、あるいはthe moonなど、任意の値として読み取られる可能性があります。この場合、操作がモデルが期待する方法と一致しないため、システムが正しくないと言えます。

これにより、システムの正しさが定義されます。操作と状態に関するいくつかのルールが与えられれば、操作が進化してもシステムは常にこれらのルールに従います。このようなルールを一貫性モデルと呼びます。

レジスタのルールは平易な英語で述べられていますが、レジスタは任意の複雑な数学的構造になることがあります。 「以前に 2 回書き込まれた値を読み取り、その値に 3 を加算し、結果が 4 の場合、読み取り操作は cat または dog を返す可能性があります」という一貫性モデルも考えられます (著者はテーブル名一貫性モデルの原理のみを説明しており、後述にも同じことが当てはまります)。 「すべての読み取り操作は 0 を返す」という意味にもなります。 「ルールは全くなく、あらゆる行動が許可されている」とも言えるでしょう。これは最も単純な一貫性モデルであり、どのシステムでも簡単に満たすことができます。

より正式には、一貫性モデルは、許可されたすべての操作の記録のセットです。プログラムを実行すると、許可された一連の操作の後に、特定の実行の結果は常に一貫しています。プログラムが誤ってセット内にない操作を実行した場合、実行記録が矛盾していると言われます。実行可能な操作がこの許可された操作セット内に存在する場合、システムは一貫性モデルを満たします。実際のシステムがそのような「直感的に正しい」一貫性モデルを満たし、予測可能なプログラムを作成できるようになることを期待しています。

同時発生の歴史

Node.js または Erlang で書かれた並行プログラムがあるとします。複数の論理スレッドがあり、これを「マルチプロセス」と呼びます。この並行プログラムを 2 つのプロセスで実行し、各プロセスが同じレジスタにアクセス (読み取りと書き込み) すると、これまで信じられていたレジスタ システムの不変性 (順序不変性のこと) が書き換えられます。

マルチプロセッサの歴史

2 つのワーカー プロセスは、「トップ」と「ボトム」と呼ばれます。トッププロセスは、写a 、读、读を実行しようとします。 Bottom プロセスは、读、写b 、读を同時に実行しようとします。プログラムは並行して実行されるため、2 つのプロセス間で操作がインターリーブされると、複数の実行順序が発生します。シングルコアのシナリオでは、実行順序は常にプログラムで指定された論理順序になります。この例では、上部がa書き込み、下部がaを読み取り、上部がaを読み取り、下部がb書き込み、上部がbを読み取り、下部がb読み取ります。

しかし、並行性により、すべてが異なる動作をするようになります。デフォルトでは、すべての並行プログラムは、一度実行されると、任意の順序で操作が発生する可能性があると想定できます。スレッド、つまり論理プロセスは、実行レコード レベルで制約を課します。つまり、同じスレッドに属する操作は順番に実行されなければなりません。論理スレッドは、許可された操作セット内の操作に対して部分的な順序付けの保証を課します。 (論理スレッドは実行エンティティです。コンパイラが命令を並べ替えても、単一スレッド内の同期ワークフローの順序は逆になりません。ただし、異なるスレッド間のイベントの順序は保証されません。)

上記の保証があっても、独立したプロセスの観点からはレジスタ不変条件は破られます。 Top はa書き込み、 a読み取り、次にb読み取りますが、これは書き込んだ値ではなくなります。並行性を効果的に記述するには、一貫性モデルをより緩やかにする必要があります。これで、プロセスは他のプロセスから最後に書き込まれた値を読み取ることができるようになりました。レジスタは 2 つのプロセス間の調整の場となり、状態を共有します。

光錐

> 読み取りと書き込みはもはや瞬間的なプロセスではなく、光の伝播 -> 反射面 -> 逆伝播に似たプロセスです。

光円錐の歴史

現実はそれほど理想的ではないことが多く、ほとんどすべての実用的なシステムでは、プロセス間に一定の距離があります。キャッシュされていない値（CPU のローカル キャッシュによってキャッシュされていない値）。通常は CPU から30 cm離れた DIMM メモリ スティック上にあります。光がこのような長距離を移動するには 1 ナノ秒かかり、実際のメモリ アクセスは光の速度よりもはるかに遅くなります。異なるデータセンターのコンピューター上にある値は、数千キロメートル離れている可能性があり、伝播時間は数百ミリ秒になります。物理法則に違反せずにこれより速くデータを伝播する方法はありません。 (現代のコンピュータ システムはもちろん、物理法則も破られています。)

これは、私たちの操作がもはや瞬時に行われないことを意味します。一部の操作はほぼ瞬時に完了するほど高速ですが、一般的に言えば、操作には時間がかかります。変数への書き込みを呼び出します。書き込みはメモリ、別のコンピュータ、または月へ伝播します。メモリの状態が変化する。確認が返送されます。つまり、その作戦が実際に行われたことが分かります。

同時読み取り

場所間でのメッセージの送信が遅れると、操作の記録に曖昧さが生じる可能性があります。ニュースがどれだけ速く、あるいは遅く広まるかによって、予期せぬ一連の出来事が起こる可能性があります。上の図では、下部が読み取り要求を開始すると値はaになりますが、読み取り要求の伝播中に上部が値をbに書き込みます。つまり、書き込み操作が読み取り要求の前に誤ってレジスタに到達します。下部はaではなくbと表示されます。

このレコードは、レジスタ同時実行一貫性モデルを破壊します。 Bottom は、読み取り要求が開始されたときの値を読み取りません。操作の真实时间として、调用时间ではなく完成时间を使用することも考えられますが、逆に考えると、これも機能しません。書き込み操作の前に読み取り要求が到着すると、プロセスは現在の値がbときにa読み取ります。

分散システムでは、操作の実行にかかる時間が長くなるため、一貫性モデルをより緩やかにし、これらのあいまいな順序の発生を許可する必要があります。

寛大さの程度をどのように決定するのでしょうか?すべての可能な順序を許可する必要がありますか?おそらく、私たちはまだ何らかの合理性の制約を課すべきでしょうか?

線形化可能性

有限同時実行境界

詳しく調べてみると、イベントの順序が制限されていることがわかります。時間ディメンションでは、メッセージを逆方向に送信できないため、最初に到着したメッセージはすぐにデータ ソースに到達します。操作は呼び出されるまで有効になりません。

同様に、完了を通知するメッセージを送り返すことはできないため、操作は完了後に有効になりません。

各プロセスに伝達されるグローバル状態があると仮定すると、そして、このグローバル状態と相互作用する操作はアトミックであると仮定し続けます。そうすれば、多くの可能性のある記録を除外できます。各操作は、その呼び出しから完了までの間のある時点でアトミックに有効になります。

この一貫性モデルを線形一貫性モデルと呼びます。操作は並行して行われ、時間がかかりますが、各操作はどこかで厳密な線形順序で発生します。

線形化可能性完全な可視性

「グローバルな単一の状態ポイント」は、必ずしも単一のノードであるとは限りません。同様に、操作は必ずしもすべてアトミックであるとは限りません。プロセスの観点からは、外部レコードが単一の原子状態ポイントに相当する限り、状態は複数のマシンに分割することも、複数のステップで完了することもできます。通常、線形化可能なシステムは、ハードウェアが線形化可能な操作を提供するまで、それ自体が線形化可能であり、さらに細かい粒度の調整されたプロセスで構成される、多数の小さな調整されたプロセスで構成されます。

線形化は強力な武器です。操作が完了すると、その操作または操作後の状態がすべての参加者に表示されるようになります。各操作は完成时间より前に実行される必要があり、その後に呼び出される操作は调用时间より後、つまり元の操作自体より後に実行する必要があるためです。 b書き込みに成功すると、後続のすべての読み取り要求でb読み取ることができるようになります。さらに書き込みが発生した場合は、 bの後の値を読み取ることができます。

線形化可能性の原子性制約を活用して、状態を安全に変更できます。レジスタが特定の値を保持している場合にのみ、レジスタに新しい値を書き込むことができるCAS（compare-and-set）のような操作を定義します。 CAS操作は、ミューテックス、セマフォ、チャネル、カウンター、リスト、セット、マップ、ツリーなどの実装の基盤として使用でき、これらの共有データ構造を利用できるようになります。線形化可能性により、変更の安全なインターリーブが保証されます。

さらに、線形化可能性の時間制限により、操作が完了すると、すべての変更が他の参加者に表示されるようになります。したがって、線形化可能性により、古い読み取りが禁止されます。各読み取りでは、调用时间と完成时间の間の状態が読み取られますが、読み取り要求呼び出し前の状態は読み取られません。線形化可能性は、最初に新しい値を読み取り、次に古い値を読み取る読み取り要求などの非単調な読み取りも禁止します。

これらの強力な制約の存在により、線形化可能なシステムは推論が容易になり、多くの並行プログラミング モデルを構築するための基礎として選択されます。 JavaScript のすべての変数は (独立して) 線形化可能であり、Java の volatile 変数、Clojure のアトム、Erlang の個々のプロセスも同様です。ほとんどのプログラミング言語は、線形化可能なミューテックスとセマフォを実装しています。強く制約された仮定は通常、強く制約された保証につながります。

しかし、これらの仮定を満たすことができない場合はどうなるでしょうか?

(線形一貫性モデルは、次の保証を提供します。1. オブザーバーの場合、すべての読み取りと書き込みは、単調に増加するタイムライン上で連続的に進みます。2. すべての読み取りは、常に最新の書き込み操作の値を返すことができます。)

連続的な一貫性

連続した歴史

プロセスが時間軸上でシフトできるようにして、その操作が呼び出される前または完了後に有効になるようにした場合でも、プロセス内の操作はプロセスで定義された順序 (つまり、プログラミングによって定義された論理的な順序) で実行する必要があるという制約が保証されます。これにより、わずかに弱い一貫性モデル、つまり順次一貫性が得られます。

順次整合性では、線形化可能な整合性よりも多くのレコードを生成できますが、それでも有用なモデルであり、毎日使用されます。たとえば、ユーザーが YouTube にビデオをアップロードすると、YouTube はそのビデオを処理キューに入れて、すぐにビデオの Web ページを返します。動画はすぐには見られませんが、アップロードされた動画が完全に処理されてから有効になるまでには数分かかります。キューは、（キューの特定の実装に応じて）キューに登録された順序でアイテムを同期的にキューから削除します。

多くのキャッシュは、順次一貫性のあるシステムと同様に動作します。 Twitter でツイートを書いたり、Facebook に投稿を公開したりすると、キャッシュ システムのレイヤーを通過するのに時間がかかります。異なるユーザーが異なるタイミングで私の情報を見ることになりますが、すべてのユーザーが同じ順序で私のアクションを見ることになります。この投稿は一度見ると消えることはありません。複数のコメントを書いた場合、他の人は順番どおりにコメントを見ることになります。

(順次整合性により、整合性の要件が緩和されます。1. 操作はリアルタイムの順序で実行する必要はありません。2. 異なるプロセス間で操作が実行される順序に必須の要件はありませんが、操作はアトミックである必要があります。3. 単一プロセス内の操作の順序は、それらがエンコードされる順序と一致している必要があります。)

カジュアルな一貫性

プロセス内のすべての操作に順序制約を課す必要はありません。因果的に関連する操作のみが順番に発生する必要があります。投稿を例に挙げてみましょう。投稿の下にあるすべてのコメントは、すべてのユーザーに対して同じ順序で表示される必要があり、投稿の下にある返信は、投稿が表示された後にのみ表示されます (つまり、投稿と投稿の下にあるコメントの間には因果関係があります)。これらの因果関係を「操作 X に依存している」という形式ですべての操作の明示的な部分としてエンコードすると、データベースは依存関係が準備されるまでそれらの操作の可視性を遅らせることができます。

因果一貫性は、同じプロセスでの各操作の厳密な順序付け (つまり、順次一貫性) よりも緩やかです。つまり、同じプロセスに属しているが異なる因果チェーンの操作は、相対的な順序で実行できます (つまり、因果関係によって分離され、因果関係のない操作は同時に実行できます)。これにより、多くの直感に反する動作の発生を防ぐことができます。

シリアル化可能な一貫性

シリアル化可能な履歴

操作が、ある単一のアトミック順序と同等であるが、呼び出し時間と完了時間に依存しないレコード内で発生する場合、シリアル一貫性と呼ばれる一貫性モデルが存在します。このモデルはあなたが思っている以上に強力であると同時に壊れやすいです。

シリアル化可能性は、時間や順序に制限を課すことなく、さまざまな種類のレコードの発生を許可するため、弱い制約です。上の図では、メッセージは過去や未来に任意に送信され、原因と結果が絡み合っているように見えます。シリアル データベースでは、 x時刻 0 で初期化されていない場合でもread xのような読み取りトランザクションが許可されます。または、無限の将来まで遅延されることもあります。 write 2 to xのような書き込みトランザクションは、すぐに実行される場合もあれば、まったく実行されない場合もあります。

たとえば、シリアルシステムでは、次のようなプログラムがあります。

 x = 1
 x = x + 1
 xを置く

このプログラムは、操作が任意の順序で発生する可能性があるため、 nil 、 1 、または2出力することができます。これは非常に弱い制約です。ここでは、コードの各行を単一の操作として考えることができ、すべての操作が正常に実行されます。

一方、シリアル一貫性も強い制約であり、線形順序を要求する場合、操作記録の大部分を傍受する可能性があります。次のプログラムを参照してください。

 x = 3 の場合はx を出力します
x = nil の場合、 x = 1
 x = 1の場合、 x = 2
 x = 2の場合、 x = 3

このプログラムでは出力は 1 つだけ可能です。書き込んだ順番通りに出力されるわけではなく、 x nilからnil -> 1 -> 2 -> 3と変化し、最終的に3出力されます。

シリアル化可能性により、操作の順序を任意に変更できます (操作の順序がアトミックである限り)。そのため、実際のシナリオではあまり役に立ちません。直列化可能性を提供すると主張するほとんどのデータベースは、実際には、線形化可能性と同じ時間制限を持つ强串行一致性を提供します。さらに問題を複雑にしているのは、ほとんどの SQL データベースが、繰り返し読み取り、カーソルの安定性、スナップショット分離など、実際に提供しているよりも低いレベルのシリアル化可能性を宣伝していることです。

(線形一貫性と直列一貫性については、非常に似ているように見えますが、そうではありません。直列一貫性は、トランザクションを対象としたデータベース分野の概念です。トランザクションのグループの実行効果が特定の直列実行と同等であることを説明します。順序付けの概念はありませんが、線形一貫性は並列コンピューティングの分野から来ており、特定のデータ構造に対する操作の連続的な特性を説明します。直列一貫性は、複数の操作と複数のオブジェクトに対する保証であり、全体的な操作順序の要件はありません。線形一貫性は、単一の操作と単一のオブジェクトに対する保証であり、すべての操作はリアルタイムのシーケンスに従います。詳細については、http://www.bailis.org/blog/lin ... lity/ を参照してください)

一貫性にはコストが伴う

前述のように、「弱い」一貫性モデルでは、「強い」一貫性モデルよりも多くの操作レコードが発生します(ここでの強いと弱いは相対的です)。たとえば、線形化可能性により、操作が呼び出されてから完了するまでの間に操作が行われることが保証されます。いずれにせよ、秩序を強制するには調整が必要です。大まかに言えば、ログ記録が頻繁に実行されるほど、システムの参加者はより注意深く、より頻繁に通信を行う必要があります。

おそらく、CAP 理論について聞いたことがあるでしょう。これは、一貫性、可用性、および分断耐性が与えられた場合、どのシステムも上記の 3 つのうち最大2 つを保証できるが、3 つすべてを満たすことはできない、というものです。これは Eric Brewer の CAP 予想を非公式に表現したものですが、正確な定義は次のとおりです。

• 一貫性とは線形化可能性を意味し、具体的には線形化可能なレジスタになります。レジスタはセット、リスト、マッピング、リレーショナル データベースなどと同等であるため、理論はさまざまな線形化可能なシステムに拡張できます。
• 可用性とは、障害が発生していないノードに対して行われたすべての要求が正常に完了することを意味します。ネットワーク分割は任意の長さで継続する可能性があるため、ノードは分割が終了するまで応答を単純に延期することはできません。
• パーティション耐性とは、パーティションが発生する可能性が高いことを意味します。ネットワークが信頼できる場合、一貫性と可用性を提供することは非常に簡単になりますが、ネットワークが信頼できない場合、一貫性と可用性の両方を提供することはほぼ不可能になります。ただし、インターネットは常に完全に信頼できるとは限らないため、CA を選択することはできません。市販されている分散システムはすべて、せいぜい AP または CP の保証しか提供できません。

家系図

「待ってください! 線形化可能性は一貫性モデルの究極のソリューションではありません! CAP 定理に基づいて、順次一貫性、直列化可能性、またはスナップショット分離を提供できます!」と言っているかもしれません。

はい、CAP 定理は、完全に使用可能な線形化可能なシステムを構築することはできないと主張しているだけです。問題は、シーケンシャル順序付け、シリアル化可能性、反復読み取り、スナップショット分離、カーソル安定性、またはこれらよりも強力なその他の制約を使用して、完全に利用可能なシステムを構築できないという他の証拠があることです。 Peter Bailis の「Highly Available Transactions」論文では、赤で塗りつぶされたモデルは完全には利用できません。

可用性の定義を緩和し、クライアント ノードが常に同じサーバーと通信できることのみを要求すると、一定の一貫性が実現されます。これを基盤として使用して、因果一貫性、PRAM (パイプライン ランダム アクセス メモリ) 一貫性、および「書き込んだ内容を読み取る」一貫性を実現できます。

完全な可用性が必要な場合は、モノトニック読み取り、モノトニック書き込み、読み取りコミット、モノトニックおよびアトミック ビューなどを提供できます。これらの一貫性モデルは、Riak や Cassandra などの分散ストレージ システムや、低い分離設定の ANSI SQL データベースによって提供されます。これらの一貫性モデルは線形順序を保証するものではありませんが、バッチ タスクまたはネットワーク シナリオでは部分的な順序の保証を提供します。より豊富なレコードを可能にするため、部分的な順序のみが保証されます。

ハイブリッドアプローチ

弱いが危険ではない

一部のアルゴリズムはセキュリティのために線形化可能性に依存しています。たとえば、分散ロック サービスを構築する場合、線形化可能性が必要になります。厳格な時間境界がない場合は、将来のロックまたは過去のロックを保持できます。一方、多くのアルゴリズムでは線形化はまったく必要ありません。 「弱い」一貫性モデルのみが提供される場合でも、最終的な一貫性が保証されるセット、リスト、ツリー、マップなどの構造は、CRDT（Commutative Replicated Data Types）として安全に表現できます。

より強力な一貫性モデルでは、操作が正しい順序で実行されるようにするために、より多くの調整、つまりより多くのメッセージングが必要になります。これは可用性が低下することを意味するだけでなく、レイテンシも高くなります。このため、最新の CPU メモリ モデルは、明示的に指定しない限り、デフォルトでは線形化できません。 (x86-64 アーキテクチャに基づく CPU は通常、デフォルトのメモリ順序としてシーケンシャル一貫性を使用します)、最新の CPU はコア間でメモリ操作を並べ替えたり、さらに悪い順序になったりします。推論するのは難しくなりますが、パフォーマンスの向上は驚くべきものです。地理的に分散された分散システムでは、データ センターのレイテンシは数百ミリ秒になることが多く、これは通常 CPU のシナリオと同様で、コストも同様です。

したがって、実際には、冗長性、可用性、パフォーマンス、セキュリティなどの目標のバランスをとるために、データベース間で異なる一貫性モデルを混在させたハイブリッドデータ ストレージがよく使用されます。可能であれば、可用性とパフォーマンスのために「弱い」一貫性モデルを選択してください。一部のアルゴリズムでは操作の順序に厳しい要件があるため、必要に応じて「強力な」一貫性モデルを選択してください。 S3、Riak、Cassandra などのデータベースに大量のデータを書き込み、その後、データへのポインターをPostgres、ZooKeeper、etcd に線形に書き込むことができます。一部のデータベースでは、リレーショナル データベースの調整可能な分離レベルや Cassandra および Riak の線形化可能なトランザクションなど、複数の整合性モデルの共存が可能であり、使用されるシステムの数を削減できます。しかし、肝心なのは、自分の一貫性モデルが最適な解決策であると主張する人は、きっと馬鹿だということです。

次は素晴らしいコメントの時間です

コリン・スコット: 「同じプロセスに属しているが異なる因果関係を持つ操作」について言及する際、基礎となる因果関係 (以前に発生したもの) についてより保守的な仮定を立てているのでしょうか?ケースを考えるのに苦労しています。潜在的な因果関係（A は B の前に発生する必要がある）を持つ同じマシンからの 2 つの操作が同時に発生するとどうなりますか?

Aphyr (著者): 同じプロセスからの操作はノード上で順番に発生しますが、すべての場所で順番に発生する必要はありません。順次一貫性はそのような制約を作成しますが、偶発的一貫性はそのような制約を作成しません。因果的に一貫性のあるシステムでは明示的な因果関係のみが順序不変ですが、順次一貫性のあるシステムでは暗黙的な因果関係が保証されます。 (これらはすべて同じプロセスから来ているため、pid によって区別されます)

Aurojit Panda: 実際のところ、 Colin Scottに対するあなたの返答と記事内の一致性层级示意图矛盾しています。 PRAM 一貫性モデルでは、すべてのノードが特定のノードからの書き込み操作を同じ順序で観察できることが規定されています (Lipton および Sandberg 1988)。あなたが説明した因果一貫性は、古典的な因果一貫性モデルではなく、PRAM 一貫性よりも弱い一貫性モデルです。また、説明に現れる暗黙の因果関係も、PRAM 一貫性モデルの制約の一部です。因果一貫性が PRAM 一貫性よりも強い場合は、因果一貫性を使用して単一ノードでの書き込み操作を正しく順序付け、他のノードの観測が一致するようにする因果一貫性システムを使用して PRAM 一貫性を実装する必要があります。

Aphyr (著者): 因果一貫性が PRAM よりも強力である理由の詳細については、https://projects.ics.forth.gr/ ... s.pdf を参照してください。具体的には、因果操作は中間ノード間で転送できますが、PRAM は因果一貫性の推移性を定義しません。

Prakash: 「シリアル一貫性の例では、さまざまなif if が順序をどのように制約しますか?」という質問に関して、回答では「これらの操作が発生する可能性のある順序は 1 つだけです」と述べられています。私の質問は、並行環境で何らかの操作を実行する場合、「シリアル化が実行できる順序は 1 つだけである」という状態をどのようにして実現するかということです。たとえば、異なるスレッドがあり、そのうちの 1 つはxの値が 3 かどうかをチェックしてそれを出力し、もう 1 つはxの値を 2 に設定します。このシナリオで順序がどのように維持されるかを説明していただけますか。

Aphyr (作者): シリアル操作記録は、実際には単一スレッドでの操作記録に変換されます。単一スレッドでの操作記録は、これまでの説明で役割を果たした状態転送方程式です。アイデンティティ関数をモデルとして使用する場合、操作ログを通過するすべての可能なパスが有効であり、状態は変更されません。特定の操作レコードをシリアル化できないようにするには (状態転送を引き起こす可能性のある不正な操作を制限するため)、シングルスレッド実行と同等の一部の操作を無効として宣言する必要があります。これが、条件文 ( if ) がいくつかの操作を強制的に順序どおりに実行する理由です。