シナリオの説明は簡単ですが、複雑な答えがある場合があります。
書き込み専用のmysqlデータベースが1つある場合を想像してみてください。次に、約5つまたは6つの読み取り専用データベースがあります。書き込みデータベースには、特定のインベントリのカウントがあります。この特定の在庫アイテムを数十万人のユーザーが叩きのめしていますが、数量は限られています。議論のために、10項目と言います。
10個のアイテムのみが販売されるようにするための最良の方法は何ですか？読み取り専用スレーブが更新される時間の間に200ミリ秒のデルタさえある場合、カウントの整合性が古くなり、所有していない在庫を販売することはできませんか？
この問題をどのように解決/スケーリングしますか？
同時ユーザーに対する基本的な解決策は、おそらくこれもカバーします。「購入」トランザクションのある時点で、(書き込みサーバーで) 在庫を減らす必要があります。どんな方法でも、在庫がゼロ以下にならないように強制します。
商品が1つ残っていて、2人がそれを買おうとすると、1人は運が悪い.
レプリケーションのレイテンシーはまったく同じです。2 人のユーザーが商品を入手できることを確認しましたが、購入しようとしたときには既になくなっていました。このシナリオの適切なソリューションは、レプリケーションの待ち時間と、ユーザーが別のユーザーの下から最後のアイテムを単純に奪い取ることの両方をカバーします。
それはすべて、更新のためにマスターテーブルをいつどのウィンドウでロックするかによって異なります。
A. 100％確実である必要がある場合、アイテムが確実に入手可能である場合にのみ、アイテムの購入が試みられます。特定のユーザーにアイテムをリストするとすぐに、そのアイテムをロックする必要があります（つまり、在庫在庫を一時的にデクリメントします）。
B.「申し訳ありませんが、在庫がなくなりました」というメッセージを表示しても問題ありません。請求する直前にアイテムをロックする必要があります（トランザクションが完了した後にロックすることもできますが、非常に猛烈な顧客を犠牲にして）
ロックにはアプローチAを選択しました。在庫が非常に少ないアイテムについては、「すぐに売り切れ」という警告のフラグを立てることができます。（非常に頻繁な状況の場合は、アイテムをヒットしている同時ユーザーの数を数え、より正確な警告を出すこともできます）
ビジネスの観点からは、在庫がそれほど少なくなりたくないでしょう（同時購入者の数よりも少ない）これはもちろん、在庫がなくても大丈夫な「クリスマス」の時期には避けられません:)