Interfaz común algoritmo de limitar

En el desarrollo de sistemas altamente concurrentes, hay tres arma utilizada para proteger los sistemas: caché, la degradación y la limitación de corriente . Entonces, ¿cuál es el límite de corriente que? Como su nombre indica, es para restringir el reductor de flujo, al igual que el tráfico de paquetes de banda ancha una G, y salir corriendo ido. Al limitar, así que podemos controlar QPS del sistema, a fin de lograr el propósito de proteger el sistema. Benpian introducirá algoritmos limitantes comunes y sus características.

algoritmos Introducción

método de contador

método de contador es el algoritmo en el más simple y más fácilmente implementado un algoritmo de limitación. Por ejemplo, nuestras disposiciones para la interfaz A, no podemos por uno visitas minuto más de 100. Entonces podemos hacer esto: en el principio, podemos establecer un contador de contador, cada vez que una petición ha terminado, se incrementa un contador, si el valor del contador 100 y el intervalo de tiempo es mayor que la petición con la primera solicitud además dentro de 1 minuto, a continuación, que demasiadas peticiones; intervalo de solicitud si la primera solicitud es mayor que 1 minuto, y también limitando el valor de margen de flujo de contador, el contador se reposiciona, el siguiente algoritmo es una vista esquemática de la específica :
imagen

Específicamente el siguiente pseudo-código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{Clase CounterDemo pública
públicas de largo timeStamp = getNowTime ();
int reqCount pública = 0;
límite int público final = 100; // número máximo de solicitudes dentro de una ventana de tiempo
público largo intervalo final = 1,000; MS // ventana de tiempo

público Boolean Grant () {
larga getNowTime = ahora ();
iF (ahora <+ intervalo de la marca de tiempo) {
// dentro de la ventana de tiempo
reqCount ++;
// determina si el número de solicitudes excede el máximo control actual ventana de tiempo
reqCount retorno <= límite;
}
la else {
timeStamp ahora = ;
// reinicio después de tiempo de espera de
reqCount = 1;.
retorno a la verdadera;
}
}
}

Este algoritmo es simple, pero hay un problema muy grave, que es la cuestión fundamental, buscamos:

imagen

Podemos ver en la figura anterior, supongamos que tiene un usuario malicioso, que estaba en doce y cincuenta y nueve, y al instante envió 100 solicitudes, y 1:00 y de inmediato envió 100 solicitudes, por lo que, de hecho, el usuario en un segundo allí, 200 solicitudes transmitidas al instante. Tenemos sólo un minuto hasta una solicitud predeterminada 100, es decir, hasta el 1,7 por solicitud, la solicitud del usuario estallar ventana de tiempo de reinicio de nodo, podemos excede el límite de velocidad al instante. Posible que el algoritmo de usuario por esta vulnerabilidad, y al instante desbordar nuestra aplicación.

amigos inteligentes pueden haber visto, de hecho, el problema es sólo porque nuestra precisión estadística es demasiado baja. Entonces, ¿cómo podemos hacer frente a este problema que muy bien? O, ¿cómo afectaría la cuestión fundamental de la reducción? Podemos ver el algoritmo siguiente ventana deslizante.

ventana deslizante

Ventana corredera, también conocida como ventana de rodadura. Para resolver este problema, se introduce un algoritmo de ventana deslizante. Si el protocolo de red TCP estudiado, entonces seguramente el término de la ventana deslizante no será desconocido. Por debajo de esta cifra, una buena explicación del algoritmo de ventana deslizante:
imagen

En la figura, el rectángulo rojo indica toda la ventana de tiempo, en nuestro ejemplo, una ventana de tiempo es de un minuto. a continuación, se divide la ventana de tiempo, tales como dibujo, que se convertirá en el marco de la ventana deslizante designado 6, de modo que cada célula está representada por 10 segundos. Cada 10 segundos, nuestra ventana de tiempo se deslizarán a la derecha un espacio. Cada rejilla tiene su propio contador contador separado, por ejemplo cuando una solicitud es 0:35 segundos, cuando se alcanza, doce y treinta ~ doce y treinta y nueve correspondiente contador se incrementa en uno.

Entonces, ¿cómo resolver el problema crítico de la ventana deslizante acaba de hacer? Podemos elegante figura, 0: 59 100 solicitudes que llegan rejilla gris a caer, y la solicitud caerá alcances 1:00 rejilla naranja. Cuando el tiempo alcanza 01:00, que se moverá a la derecha de un marco de ventana, a continuación, en este momento el número total de solicitudes dentro de una ventana de tiempo de un total de 200, 100 excede el límite, por lo que en este caso es posible detectar la corriente de disparo limitar .

Me miro de nuevo solo contador algoritmo, podemos ver que, de hecho, deslizando algoritmo contador algoritmo de ventana. Simplemente no divide aún más la ventana de tiempo, por lo que sólo una rejilla.

Por lo tanto, cuando más de cuadrícula dividida ventana deslizante, más desplazamiento suave ventana deslizante, lo que limita las estadísticas será más precisa.

Algoritmo de cubo que pierde

Leaky algoritmo de cubo, también conocido como el cubo agujereado. Para entender el algoritmo de cubeta con goteo, nos fijamos en el diagrama del algoritmo:
imagen

Podemos ver en la figura, todo el algoritmo es realmente muy simple. En primer lugar, tenemos una capacidad de cañón fijo, hay agua en el agua que hay. Para el flujo de agua que entra, no podemos esperar que un total de la cantidad de agua fluirá en, no se puede esperar para acelerar el flujo de agua. Sin embargo, para fluir fuera del agua, este caudal puede fijarse a cabo bañera. Por otra parte, cuando la cubeta está llena, el exceso de agua se desborde.

Vamos a pedir agua en la aplicación práctica del algoritmo, podemos ver el algoritmo de cubeta con goteo es de por sí limita la velocidad de la solicitud. Cuando se utiliza un algoritmo de cubeta con goteo, podemos asegurar que la interfaz será una tasa de velocidad constante para procesar la solicitud. Así cubo agujereado algoritmo problema crítico no se produce de forma natural. Específicamente, el siguiente pseudocódigo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{Clase LeakyDemo pública
pública a largo timeStamp = getNowTime ();
int capacidad pública; // capacidad de la cuchara
tasa public int; // fugas de agua tasa
int público de agua; // corriente de agua (el número acumulado actual de solicitudes)

pública de Boole Grant () {
larga getNowTime = ahora ();
agua = max (0, agua - (ahora - timeStamp) * Rate); // primera fugas de agua, se calcula el agua restante
    timeStamp = ahora;

    IF (. (agua + 1) <Capacity) {
    / / intentar añadir agua, y más en agua bajo
    agua + = 1;.
retorno a la verdadera;
}
la else {
// lleno de agua, añadir basuras agua
de retorno en false;
}
}
}

Token Bucket algoritmo

Token algoritmo de cubo, también conocido como el cubo simbólico. Para entender este algoritmo, entonces fijamos en el diagrama del algoritmo:

Podemos ver en la figura, el algoritmo de cubetas de fichas es un poco más complejo que el algoritmo de cubo agujereado. En primer lugar, tenemos un cubo-capacidad fija, cubo mantuvo el testigo (token). Comenzando un cubo está vacío, r token en el cubo se llena con una tasa fija hasta que la capacidad de la cuchara, se descartarán tokens excedentes. Cada vez que una solicitud ha terminado, se intente retirar una muestra de la cubeta, si no razón, no puede por encargo.

Específicamente, el siguiente pseudocódigo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class TokenBucketDemo {
public long timeStamp = getNowTime();
public int capacity; // 桶的容量
public int rate; // 令牌放入速度
public int tokens; // 当前令牌数量

public boolean grant() {
long now = getNowTime();
// 先添加令牌
tokens = min(capacity, tokens + (now - timeStamp) * rate);
timeStamp = now;
if (tokens < 1) {
// 若不到1个令牌,则拒绝
return false;
}
else {
// 还有令牌，领取令牌
tokens -= 1;
return true;
}
}
}

临界问题

Consideremos el problema de la escena crítica. En 0:59 segundos, ya que el barril 100 llena con el token, por lo que esta solicitud 100 por instantáneamente. Sin embargo, puesto que el contador se llena en una tasa más baja, de modo que a las 1:00, cuando no se puede alcanzar el número de cubetas de fichas 100, a continuación, en este momento no existen solicitudes más largos 100 a través. Por lo tanto, el algoritmo de cubetas de fichas puede resolver los problemas críticos. La siguiente tabla compara los contadores (izquierda) y el algoritmo de cubetas de fichas (derecha) en una velocidad de cambio del punto crítico. Podemos ver que la tasa mientras que el algoritmo de cubetas de fichas permite estalló, pero de una velocidad de tiro hay que esperar a que el colector de testigos ha suficiente para producir:
imagen

resumen

VS ventana deslizante contador

Contador algoritmo es el algoritmo más simple, puede ser visto como una precisión baja deslizamiento implementación de una ventana. Ventana corredera debido a la necesidad de almacenar una pluralidad de piezas contrarias (cada cuadrícula de un depósito), la ventana deslizante requiere más espacio de almacenamiento en la realización. Es decir, si el más exacto de la ventana deslizante, mayor es la necesidad de espacio de almacenamiento.

Cubo que pierde algoritmo VS Token Bucket algoritmo

Cubo que pierde algoritmo y el algoritmo de cubetas de fichas La más obvia diferencia es que el algoritmo de cubetas de fichas permite un cierto grado de ráfagas de tráfico. Debido a que el defecto de contadores algoritmo de cubo, no requiere la eliminación consume tiempo del contador, es decir, cuando el barril ha asumido contador 100, entonces solicita 100 puede permitir al instante a través.

Debido a que el algoritmo de cubetas de fichas es simple y permite que algunas ráfagas de tráfico, fácil de usar, por lo que la industria está utilizando más tierra. Por supuesto, necesitamos condiciones específicas, sólo el algoritmo más adecuado no es algoritmo óptimo.