なぜ必要なのか

読者が記事を読み、読書リストを保存する図書館アプリを作るとします。運営側は継続して待ち受けるプロセスと再起動を直接制御する必要があり、個別の呼び出し単位の管理では要件に合いません。記録の保存だけが選ぶ理由ではありません。

どう解決するのか

記事の閲覧と図書館の読書リストの保存は待機中のプロセスに入ります。保存は外部ストアに記録します。再保存しても例の読者・記事キーにより記録は1件です。次の保存を失敗させるとストアを変えず失敗を返します。処理器の再起動はプロセスだけを置き換え、記録を残します。リセット・再読み込みは仮想ストアを含むページメモリ全体を消します。

プロセス再起動と記録の維持

概念シミュレーション

常時稼働サーバー

公開記事を読み、図書館の読書リストを保存します。再送も美奈 / 図書館の読書リストを共有します。

01 · 待機プロセス · 再起動の境界

GET

ブラウザー → 待機プロセス → 記事HTML

POST 図書館の読書リスト

ブラウザー → 待機プロセス → 外部ストア → 確認応答。

実行世代: 1 · この世代の呼び出し: 0

実行環境の担当
製品チーム / 運用担当
容量の費用
待機中も確保
復旧の責任
監視・再起動・復元

待機

ストアもページメモリ上の模型です。再起動では残り、リセット・再読み込みで消えます。重複防止は独自のアプリ処理です。

本文内の架空のデモです。リセット・再読み込みで初期状態に戻ります。

どんな考え方なのか

常時稼働サーバーはプロセスが継続してリクエストを待つ運用を意図します。再起動は起こるため、名前が無停止を保証するわけではありません。

永続データは外部に置き、監視・容量・復旧の担当者を決めます。

出典