最近、グループはスパイクと電流制限についておしゃべり、私は同様のアプリケーションを実行していないが、仕事はより多くのデータおよび同時実行が発生しました。
したがって、我々は前方に単純なモデルを置きます：
VARカウント= rds.inc（キー）;
（数> 1000）スロー「が奪われました！」の場合
Redisのシングルスレッドモデルでは、そのincはそれぞれプラス1は、その結果、プラス1を返すことを確実にするため、安全です。オリジナルが234である場合は、プラスワンは235で、235本の途中で戻らなければならない、リターン236またはその他の結果として他の割り込み要求はありません。
実際には、我々は、株式会社ビジネスがチケットを見ることを得るためにキューイング後、ピットライン、ピットのための各会計に計上されて、その後少し過剰、および運用レベルの出力スパイクの結果ではありません理解し、より一層複雑なビジネスの一部を行うことができます。
六つの制限述べたように、いくつかの考慮に基づいていてもよい、1000の近傍のカウントに対応するキー、1％の許容される偏差を制限することが望ましいです。
だから、改善モデルと：
VARカウント= rds.inc（キー）;
もし（数> 1000）{
rds.dec(key);
throw "超出限额！"
}
彼は小さなチケットバックカットに、限度を超えた後、追加しました_
そのような多くのアプリケーション・サーバーのサポートとして、Redisのを使用する利点の1つは、一緒に急いで......
もちろん、スパイクの非常に大きな数のために、このモデルは、このような10万携帯電話に、次に3億ユーザーに銃のように、必ずしも合理的ではなく、即座に乗ります。
ここで試すことができます回避策はだ、それは10 Redisのインスタンス、各プット百万準備ができています。時間をかけて、ユーザによって要求され、それは、対応する買いを見つけるために、たとえば、乱数またはハッシュモジュロことができます。
同様に、私たちは、シーンに、より多くのユーザーを指示することができます。一般的に、ランダムなハッシュは、特定の統計的有意性を有するデータ大きく、相対的にバランスされます。
その後、スパイクの数が多い、小さなデータシナリオの簡単なシーンは、上記のでしょうか？例えば、唯一の十同時シーンの何千もの。
小さなデータシナリオ、単一のアプリケーションインスタンスは、Redisのは、州を与えたことを検討してください。
主なモデル：
Interlocked.Increase（参照回数）。
もし（数> = 1000）投げる "それを盗みます！"
中級モデル：
プライベート揮発性のInt32数;
そこ古い= 0;
行う {
old = count;
if(old >= 1000) throw "抢光啦！"
}しばらく（+ 1、古い）Interlocked.CompareExchange（参照回数、古い=古いです！）。
CASアトミック操作がアトミック比較およびスワップデータ処理レベルを保証する、CMPXCHGが処理x86命令セットに特別な指示があり、非常に良好です。ほとんどの交差しきい値システムが100,000百万〜1 TPS TPSスナップしたい、時にはABAの問題があるが、あなたは、CASが最も簡単であるロックフリーのロックフリー操作に持っているが、我々は多くを見つけることができますソリューション。
https://blog.csdn.net/qq_28666081/article/details/83043215
https://blog.csdn.net/ju_362204801/article/details/87931992
https://blog.csdn.net/fayeyiwang/article/details/51234457
