シナリオ分析
赤い封筒を掴むシナリオを例にとると、要件は次のとおりです:
1.红包有个数限制,假设红包的个数限制为X。 2.红包金额上线限制,假设金额上线为Y。 3.要求用户抢红包的时候,不超过红包的个数限制X。 4.要求用户抢红包的时候,不超过红包的金额Y。 5.每个用户一次红包活动只能抢一个。
最も一般的なアイデアは次のとおりです:
1.在用户抢红包时,检查当前发出去红包数量和金额,并加锁。 2.检查红包数量和金额正常的后,随机用户红包金额。 3.然后修改红包发出去的数量和金额,并给用户赠送红包,然后解锁。
1.思路简单 2.编不下去了。。。
1.锁数据回造成大量进程等待,造成浪费资源。 2.锁造成的等待,用户体验奇差。 3.对于锁机制不太了解的同学会产生一定的危险性。
まず、なぜ従来のアイデアが遅いのかを分析してください。
1.在抢红包的时候,每次都需要检查红包的上限 X 和 Y。 2.锁会造成大量进程卡顿。 3.生成红包的金额时还需要检查与上限 X 跟 Y 是否有冲突。
例えば、赤い封筒の数の上限はX、量の上限はYです。
その後、イベントの前に、これらの X 枚の赤い封筒をデータベース
に挿入し、シリアル番号 HB1、HB2、HB3 を生成します。 。 。 。 HBX
実際、ユーザーはこの整然とした赤い封筒のキューを順番に受け取るだけで済みます。
この操作により、その時点でオンラインで行われる多くの計算が削減されます。最も重要なことは、アクティビティ全体の制御性を簡単かつ効果的に確保できることです。
ここでは ID 生成テーブルが使用され、user_id の一意のインデックスが確立されて、各人が 1 つのシリアル番号のみを取得できるようになります。
1.活动创建之前,创建一张ID生成表,ID从 1 开始自增,且 user_id 唯一。 2.活动开始,用户开始抢红包操作。 3.抢红包之前,先插入ID表,获取插入ID,如果ID > X,通知用户已被抢完。 4.如果 ID <= X,那么恭喜了,去红包表领取序号为 ID 的红包,并走异步发红包过程。 5.活动结束之后,把相关用户领取信息存储在红包表,删除ID生成表。
1.不需要代码实现锁机制。 2.逻辑简单。 3.mysql保证每个用户只能拿到一个,且有序。
一部の友人は、赤い封筒の情報を保存するためにredisキューを使用できると述べましたが、実際には、redisはより多くのメモリを消費します。データを長期間保存する必要がある場合は、 mysql に保存するのが最善です。実際、ここで redis の incr コマンドを使用すると、上記の ID 生成テーブルと同様の関数を取得できます。これは、より高速かつ厳密にインクリメンタルであり、プロジェクト全体の同時実行性を高めることができます。
【関連する推奨事項】
以上がプロジェクトの同時実行性を高めるにはどうすればよいでしょうか? ID の自動インクリメントを使用してキューの順序を確保するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。