举例，假设有100个请求node服务器，每个请求会执行一次查询，修改数据库操作。假设10个请求按顺序被node接收处理 等待各自判定库存查询数据库io操作，但是库存只有5个，问题来了，这时候10个查询都判定库存还有，然后继续下面的下单操作。当100个请求甚至更多时，问题会被更加放大 又不能同步加锁，哪位朋友有比较合理的思路 不吝赐教～
走同样的路，发现不同的人生
サイトで「snap up」を検索https://segmentfault.com/sear...
極端なケースは「フラッシュセール」ですhttps://segmentfault.com/sear...
この場合、トランザクションを追加する必要があります
----- 回答を更新します -----
クエリと実際のデータの不一致の問題は避けられませんが、私の理解では、コールバックを更新する前に他のユーザーが購入に成功した場合、購入失敗の問題が発生するため、実際にはロックすることで解決できます。 , すべての非同期操作で Promise を使用する場合、Promise を介して連続呼び出しをシミュレートして、Java メソッドのロックと同様の機能を実現できます
デコレータを使用して、Promise を返すメソッドの Java synchronized キーワードと同様の同期呼び出しを実装します
Chrome で実行するとパスします。 。
----- 再度更新 ----
github にはすでに同様のツールがありますhttps://github.com/sindresorh...
上記の 2 人に感謝します。まず、私が説明したシナリオは通常の商品販売の場合です。これは、redis キューを使用することで直接解決できます。製品の種類が多い場合、この方法はお勧めできません。
トランザクション + 条件付き更新は、設計により過剰販売を回避します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
サイトで「snap up」を検索
https://segmentfault.com/sear...
極端なケースは「フラッシュセール」です
https://segmentfault.com/sear...
この場合、トランザクションを追加する必要があります
----- 回答を更新します -----
クエリと実際のデータの不一致の問題は避けられませんが、私の理解では、コールバックを更新する前に他のユーザーが購入に成功した場合、購入失敗の問題が発生するため、実際にはロックすることで解決できます。 , すべての非同期操作で Promise を使用する場合、Promise を介して連続呼び出しをシミュレートして、Java メソッドのロックと同様の機能を実現できます
デコレータを使用して、Promise を返すメソッドの Java synchronized キーワードと同様の同期呼び出しを実装します
リーリーChrome で実行するとパスします。 。
----- 再度更新 ----
github にはすでに同様のツールがあります
https://github.com/sindresorh...
上記の 2 人に感謝します。まず、私が説明したシナリオは通常の商品販売の場合です。これは、redis キューを使用することで直接解決できます。製品の種類が多い場合、この方法はお勧めできません。
リーリートランザクション + 条件付き更新は、設計により過剰販売を回避します。