分散システムに制限することで、システムの現在の容量は、訪問する時間の大きな量を維持するのに十分ではない、我々は圧力を維持するためにシステムへの着信要求を停止する場合は、頻繁に、言及したトピックです
シンプルな電流制限
まず、私たちは、単純な一般的な制限政策を見て、システムが一定時間操作のみN回の内の各ユーザーの行動を制限するために、データ構造がどのようにこれはそれを制限するのRedis実現しています。
ソリューション
この需要はスコア値はZSETデータ構造が時間ウィンドウのスコアに囲まれてはならないと思い、制限スライディング時間ウィンドウが存在します。そして、私たちがこれだけ時間ウィンドウのデータ外を保持する必要があり、窓はカットすることができます。このZSETフィルがより良い何であると値はありますか？それだけで、それはミリ秒単位のタイムスタンプを使用し、スペースのより多くの廃棄物をUUID使用しますが、保証の一意性に必要です。
示されているように、利用者の記録行動履歴には、構造をZSET行動の各キーZSETとして保存されます。ZSETレコードと行動の同じ種類を持つユーザー。
メモリを節約するために、我々は唯一の時間ウィンドウ内に記録保持挙動を必要とし、ユーザーは寒さの中、ユーザーの行動であれば、時間ウィンドウをスライドすると、空のレコードで、このZSETはスペースを取りません、メモリから削除することができます。
現在の行動を比較して描画することができますが、統計的しきい値MAX_COUNTスライディングウィンドウ内の行動の数によって許可されています。以下のコードで表現：
public class SimpleRateLimiter {
private Jedis jedis;
public SimpleRateLimiter(Jedis jedis) {
this.jedis = jedis;
}
public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) {
String key = String.format("hist:%s:%s", userId, actionKey);
long nowTs = System.currentTimeMillis();
Pipeline pipe = jedis.pipelined();
pipe.multi();
pipe.zadd(key, nowTs, "" + nowTs);
pipe.zremrangeByScore(key, 0, nowTs - period * 1000);
Response<Long> count = pipe.zcard(key);
pipe.expire(key, period + 1);
pipe.exec();
pipe.close();
return count.get() <= maxCount;
}
public static void main(String[] args) {
Jedis jedis = new Jedis();
SimpleRateLimiter limiter = new SimpleRateLimiter(jedis);
for(int i=0;i<20;i++) {
System.out.println(limiter.isActionAllowed("laoqian", "reply", 60, 5));
}
}
}
このコードは、適切に噛むためにいくつかの時間を過ごすためにリーダを必要とするやや複雑です。すべての行為はすぐに、時間の窓を維持する場合：それは全体的なアイデアは、これであるのです。窓の外のレコードのすべての時間は、ウィンドウ内のレコードのみを残して、きれいにします。ZSETコレクションが唯一の値が非常に重要であり、スコア、特別な意義の値値は、ちょうどそれはそれで一意であることを確認してください。
これらの操作キーを有する連続Redisのためのものであるので、パイプラインのRedisの使用が大幅にアクセス効率を向上させることができます。しかし、この解決策は、その欠点があり、それは量が多い場合には、そのような操作は、60年代には100ワット回、この引数を限度を超えてはならない、時間ウィンドウ内のすべてのレコードを記録するように作用するので、制限して行うことは適切ではない、なぜなら収納スペースの多くを消費します。