principle-separate-before-serializing-shared-state

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

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

理由： 共有状態への同時書き込みは、断続的に発生し、再現が難しく、デバッグに多大なコストがかかる競合状態を引き起こします。エージェントやゴルーチンに「順番に処理する」よう伝えても、うまくいきません。

パターン：

1. 共有される可変状態を特定します（両方が読み書きするファイル、両方がプッシュするブランチ、両方が定義して利用する API）。
2. 原則として、共有の書き込み先をなくします。 これらのアクターに必要なのは、正規の単一オブジェクトでしょうか。それとも、個別に発行される独立した情報でしょうか。各アクターに専用のファイル、キー、ブランチ、または状態ディレクトリを割り当て、読み取り／レポートの段階でのみマージします。2 つのワーカーが、1 つの state.json にそれぞれ独自の lastX フィールドを書き込むのも、共有状態の変更です。indexer-state.json と metrics-state.json に分ければ、共有状態の変更にはなりません。
3. 1 つの共有の書き込み先が実際に不変条件として必要な場合に限り、ロックファイル、逐次フェーズ、単一書き込みアクター、またはアトミックな比較交換によって、アクセスを構造的に直列化します。「ロックが必要」という考えは、既定の答えではなく、設計上の問題の兆候として確認してください。