principle-separate-before-serializing-shared-state

共有状態をシリアライズする前に分離する

並行して動作するアクターが可変状態を共有する可能性がある場合は、まず同じ可変オブジェクトを必要としているか確認してください。必要でないなら、共有をなくします。共有が避けられない場合は、ロックファイル、逐次実行フェーズ、排他的な所有権などを使って、構造的にアクセスを直列化します。指示や慣習は、並行制御の代わりにはなりません。

理由： 共有状態への並行書き込みは、発生が不定期で再現しにくく、デバッグに多大なコストがかかる競合状態を引き起こします。

パターン：

1. 共有されている可変状態を特定します（双方が読み書きするファイル、双方がプッシュするブランチ、双方が定義して利用する API）。
2. まず、共有書き込み先をなくします。 これらのアクターに必要なのは単一の正規オブジェクトですか。それとも、独立した情報を公開しているだけですか。それぞれのアクターに専用のファイル、キー、ブランチ、状態ディレクトリを割り当て、読み取りやレポートの境界でのみ統合します。2 つのワーカーが、それぞれの lastX フィールドを 1 つの state.json に書き込む場合も、依然として共有状態の変更です。indexer-state.json と metrics-state.json に分ける場合は、共有状態ではありません。
3. 共有の書き込み先が真に不変条件となる場合に限り、 ロックファイル、逐次実行フェーズ、単一ライターのアクター、アトミックな比較交換などを使って、構造的にアクセスを直列化します。「ロックが必要だ」という考えは、デフォルトの解決策ではなく、設計上の問題を確認するための兆候として扱ってください。