売り切れと分かった商品を、何度も確認しないようにした
売り切れを正しく判定できるようにしても、その商品が次の確認候補へ何度も入り続ければ、裏側では同じ仕事を繰り返します。判定を直すだけでなく、次回の仕事を作る入口まで見直す必要がありました。
SECTION 01
完了したはずの商品が、次の確認候補へ戻っていた
詳細確認で売り切れを受け取った商品でも、次回確認日時の条件だけを見ると再び候補へ入ることがありました。
その結果、売り切れ商品が処理待ちの枠を使い、販売中の商品確認が後ろへ回る可能性がありました。
SECTION 02
仕事を作る前に、現在の在庫状態を見る
詳細確認タスクを作成する段階で、すでに売り切れとして保存されている商品を除外します。
実行後に弾くのではなく、キューへ入れる前に対象外とすることで、ワーカー、通信、DBのいずれにも不要な負担を増やしません。
FLOW
売り切れ確認後の流れ
状態保存
利用できない状態を記録します。
次回除外
新しい詳細確認を作りません。
他を確認
販売中の候補へ処理枠を使います。
SECTION 03
売り切れ判定と商品違いの防止は分けて考える
タイトルや価格を取得できなくても、対象の商品IDと売り切れ状態を確認できる場合があります。
ただし、別の商品IDが返った場合まで売り切れとして受け入れると誤更新になります。対象商品の一致を確認する安全策は維持しています。
SECTION 04
処理を速くする前に、不要な仕事を減らす
ワーカーを増やすと処理量は上がりますが、不要な仕事も同じだけ速く回ってしまいます。
状態が確定した商品を入口で外すほうが、全体の待ち時間と運用コストを素直に減らせます。
QUESTIONS
よくある質問
記事の内容に関連して、検索されやすい疑問を短く整理します。
Q1売り切れ商品は二度と確認されないのですか?
現在の在庫状態が売り切れとして確定している間は、定期的な詳細確認の新規候補から外します。再開を検知する別の運用がある場合は、その状態更新後に対象となります。
Q2一時的な取得エラーも売り切れとして除外されますか?
単なる解析失敗ではなく、対象商品と利用不能状態を確認できた結果だけを売り切れとして扱います。
RELATED ARTICLES