秒殺シーン実践の現金入り封筒
秒殺シーンの実践の現金入り封筒の常用解決策
記事のアドレス:https://blog.piaoruiqing.com/blog/2019/09/01/秒殺シーン実践の現金入り封筒1/
前言
秒殺シーンは生活の中でほとんど随所に見られ、商品の買い占め、春運の切符の買い取り、随所に見られるお年玉にかかわらず、秒殺のシーンに及ぶ.面接では、秒殺業務のデザインも人気のある面接官と応募者が興味津々だ.
次に、本文は秒殺シーンにおける現金入り封筒の実現方案について分かち合い、現金入り封筒業務によく見られる実現方案、ボトルネックと最適化を含む.
ぶんせき
シーン
お年玉の応用シーンは多く、ランダムお年玉、定額お年玉など、他の販促業務を組み合わせたお年玉の変種、例えばショッピング手当などもある.しかし、技術的な観点から見ると、遊び方がどれだけ変わっても、その核心は似ています.安定:突発的な大流量を担ぐことができ、お年玉の配布に成功することを確保する. 正確:データは必ず正確で、超過配布はできない.
ビジネス
現金入り封筒を奪うのは業務の需要の違いによって多くの変種が発生する可能性があり、設計上は十分に抽象的で、現金入り封筒を奪うために買い物手当の現金入り封筒と似たようなコードを書くことはできない.現金入り封筒の後置操作はメッセージとして、異なる業務モジュールが自分で処理することができる.
ぎじゅつ
現金入り封筒の核心業務は複雑ではなく、その肝心な点は高合併、資源の競合などに対応することである.高同時:非同期、横方向拡張負荷等化、限流など. 読み書きが少ない:キャッシュ. 資源の競合:原子操作、キャッシュ或いはデータベースなどの面で制御することができる.Luaスクリプトを用いる在庫削減操作を行う.
シナリオ1-事前割当
適用シーン
お年玉の数量は相対的に合理的で、在庫が残っている場合、ユーザーレベルが大きくない場合が少ない.の利点:シンプルでキャッシュに合わせて高同時性 に対応しやすい不足:大量のお年玉を頻繁に発行すると、一度に大量の分配記録を書き込むことになり、受け取る人が多くなければ、多くの無効なデータが発生する.
簡単な説明
プリアサイメントは、お年玉を発行する際に、お年玉の総額と数量に基づいて、既定のアルゴリズムに従ってアサイメントを行い、事前にすべてのお年玉アサイメント記録を作成する.受け取るときはお年玉の配分記録を更新するだけです.
システムに適合するお年玉(あるラベルのすべてのユーザーグループに対して、出すお年玉は基本的に受け取り終わる)は、ユーザーグループに適合しないお年玉(お年玉を受け取る人数をコントロールできない場合、お年玉の個数がグループの人数よりはるかに大きい場合、無効なデータが多く、例えば1つの10グループに1000のお年玉を発行する).
実装の詳細
プロセスは、現金入り封筒を奪う前に、現金入り封筒の受領記録を予め割り当てる、受領記録のユーザIDは負の値である. 強盗後、唯一お年玉を受け取る入り口 を開放した.受領操作核心はお年玉の分配記録を更新することである: お年玉の発行記録
ID
合計金額
数量
...
1
100
3
...
お年玉の配分記録
unique:
ID
お年玉ID
金額
ユーザIDを受け取る
受領時間
...
1
1
10
-1
0
...
2
1
60
-2
0
...
3
1
30
-3
0
...
コメント に予め割り当てる は一般的な流量の小型活動に対して、この方式は簡単で、コストが低く、キャッシュを導入しない場合はMySQL 1個で基本的に担ぐことができる.
[著作権声明]本稿は朴瑞卿のブログに発表され、非商業用途の転載を許可したが、転載は原作者の朴瑞卿とリンク:blog.を保留しなければならない.piaoruiqing.com. ライセンスに関する協議や協力があれば、メールボックスに連絡してください[email protected].
シナリオ2-リアルタイム割当
適用シーン
受給者数が見積もることができず、返金が頻発している.例えば、グループのお年玉(残りの返金が頻繁に発生する)
実装の詳細
プロセス強盗を開始する前にお年玉情報をキャッシュにロードし、最初のロード時間は より長くなります.現金入り封筒:キャッシュから読み取り(なければロード)、現金入り封筒を割り当てた後、原子更新キャッシュ(発行済みであれば直接失敗に戻る) キャッシュ更新後のデータベースへの書き込み(データの正確性の検証) お年玉の発行記録
ID
合計金額
数量
残高
残りの数
...
1
100
3
100
3
...
お年玉の配分記録
unique:
ID
お年玉ID
金額
ユーザIDを受け取る
受領時間
...
...
...
...
...
...
コメント初回キャッシュのロード時間は少し長い:お年玉のリリース開始時に大きなバースト流量がある可能性があり、この時DBに行ってキャッシュをロードするのは適切ではない. キャッシュはデータベースの保証と強く一致しなくてもよい:データの正確性はデータベースによって維持され、例えば:キャッシュはお年玉の額を差し引いたが、データベースを更新する時に異常が発生し、この時キャッシュはロールバックする必要はなく、キャッシュが失効した後に再ロードすればよい.(したがって、キャッシュ時間は数秒で、あまり長くはかかりません) 更新キャッシュは、Luaスクリプトを用いる原子性を保証することが考えられる. リアルタイム分配のお年玉は無効な記録を生じず、多くのシーンに適しているが、事前分配よりも複雑である.
詳細と最適化クライアントのクリック周波数制御はある程度流量を減少することができる. お年玉を受け取った後、キャッシュの1階ですべての要求をブロックし、直接失敗に戻る. ゲートウェイ層が限流.
締めくくり
秒殺シーンは、高同時性、読み書きの少なさ、リソースの競合が特徴であり、各ポイントは、キャッシュを使用して頻繁に読み取る問題を解決し、キューを使用してデータベースのパフォーマンスのボトルネックを解決するなど、ビジネスシーンに応じて適切な解決策を選択する必要がある.
お年玉を奪う業務にとって、事前分配とリアルタイム分配はいずれも有効な方案であり、それぞれ優劣があり、具体的にどの種類を選ぶかは、やはり業務の需要にかかっている.
公众号に注目してください:(コードは诗のようです)[著作権声明]本文は朴瑞卿のブログに発表して、非商业の用途の転载を许して、しかし転载は必ず原作者の朴瑞卿とリンクを保留しなければなりません:blog.piaoruiqing.com. ライセンスに関する協議や協力があれば、メールボックスに連絡してください[email protected].
記事のアドレス:https://blog.piaoruiqing.com/blog/2019/09/01/秒殺シーン実践の現金入り封筒1/
前言
秒殺シーンは生活の中でほとんど随所に見られ、商品の買い占め、春運の切符の買い取り、随所に見られるお年玉にかかわらず、秒殺のシーンに及ぶ.面接では、秒殺業務のデザインも人気のある面接官と応募者が興味津々だ.
次に、本文は秒殺シーンにおける現金入り封筒の実現方案について分かち合い、現金入り封筒業務によく見られる実現方案、ボトルネックと最適化を含む.
ぶんせき
シーン
お年玉の応用シーンは多く、ランダムお年玉、定額お年玉など、他の販促業務を組み合わせたお年玉の変種、例えばショッピング手当などもある.しかし、技術的な観点から見ると、遊び方がどれだけ変わっても、その核心は似ています.
ビジネス
現金入り封筒を奪うのは業務の需要の違いによって多くの変種が発生する可能性があり、設計上は十分に抽象的で、現金入り封筒を奪うために買い物手当の現金入り封筒と似たようなコードを書くことはできない.現金入り封筒の後置操作はメッセージとして、異なる業務モジュールが自分で処理することができる.
ぎじゅつ
現金入り封筒の核心業務は複雑ではなく、その肝心な点は高合併、資源の競合などに対応することである.
シナリオ1-事前割当
適用シーン
お年玉の数量は相対的に合理的で、在庫が残っている場合、ユーザーレベルが大きくない場合が少ない.
簡単な説明
プリアサイメントは、お年玉を発行する際に、お年玉の総額と数量に基づいて、既定のアルゴリズムに従ってアサイメントを行い、事前にすべてのお年玉アサイメント記録を作成する.受け取るときはお年玉の配分記録を更新するだけです.
システムに適合するお年玉(あるラベルのすべてのユーザーグループに対して、出すお年玉は基本的に受け取り終わる)は、ユーザーグループに適合しないお年玉(お年玉を受け取る人数をコントロールできない場合、お年玉の個数がグループの人数よりはるかに大きい場合、無効なデータが多く、例えば1つの10グループに1000のお年玉を発行する).
実装の詳細
プロセス
-- (￣▽￣)"
UPDATE IGNORE record SET user_id = {userId}, gmt_receive = UNIX_TIMESTAMP() WHERE red_envelop_id = 1 AND user_id < 0 LIMIT 1;
-- red_envelop_id + user_id ID
合計金額
数量
...
1
100
3
...
お年玉の配分記録
unique:
ID + ID ID
お年玉ID
金額
ユーザIDを受け取る
受領時間
...
1
1
10
-1
0
...
2
1
60
-2
0
...
3
1
30
-3
0
...
コメント
UPDATE IGNORE ... LIMIT 1 :資源の競合問題を解決し、同時にお年玉の受け取りを要求するデータの正確性を確保した.red_envelop_id+user_id:インデックスを作成して一意の制約を行い、同じお年玉に対して同じユーザーが一度しか受け取ることができないことを確保する.user_idは負の値である:red_envelop_id+user_idに一意の制約があるためである.[著作権声明]本稿は朴瑞卿のブログに発表され、非商業用途の転載を許可したが、転載は原作者の朴瑞卿とリンク:blog.を保留しなければならない.piaoruiqing.com. ライセンスに関する協議や協力があれば、メールボックスに連絡してください[email protected].
シナリオ2-リアルタイム割当
適用シーン
受給者数が見積もることができず、返金が頻発している.例えば、グループのお年玉(残りの返金が頻繁に発生する)
実装の詳細
プロセス
ID
合計金額
数量
残高
残りの数
...
1
100
3
100
3
...
お年玉の配分記録
unique:
ID + ID ID
お年玉ID
金額
ユーザIDを受け取る
受領時間
...
...
...
...
...
...
コメント
詳細と最適化
締めくくり
秒殺シーンは、高同時性、読み書きの少なさ、リソースの競合が特徴であり、各ポイントは、キャッシュを使用して頻繁に読み取る問題を解決し、キューを使用してデータベースのパフォーマンスのボトルネックを解決するなど、ビジネスシーンに応じて適切な解決策を選択する必要がある.
お年玉を奪う業務にとって、事前分配とリアルタイム分配はいずれも有効な方案であり、それぞれ優劣があり、具体的にどの種類を選ぶかは、やはり業務の需要にかかっている.
公众号に注目してください:(コードは诗のようです)[著作権声明]本文は朴瑞卿のブログに発表して、非商业の用途の転载を许して、しかし転载は必ず原作者の朴瑞卿とリンクを保留しなければなりません:blog.piaoruiqing.com. ライセンスに関する協議や協力があれば、メールボックスに連絡してください[email protected].