Una tarea clave de los sistemas WEB altamente cargados es la capacidad de procesar una gran cantidad de solicitudes. Este problema se puede resolver de diferentes maneras. En este artículo, propongo considerar un método inusual para optimizar las solicitudes de back-end a través de la tecnología de rango de contenido (rango). Es decir, reducir su número sin perder la calidad del sistema a través del almacenamiento en caché eficiente.
Para empezar, propongo estudiar
un artículo en el que la tecnología preámbulo con un ejemplo para S2S se presenta de manera muy concisa e inteligible. Además, es recomendable familiarizarse con mi primer
artículo sobre el uso de esta tecnología para optimizar el trabajo con datos de mercado en un proyecto de intercambio de criptomonedas.
En este artículo, quiero mostrar que esta tecnología puede usarse más ampliamente que el primer artículo demostrado. Permítame recordarle que la información comercial (
velas ) se obtiene mediante solicitudes de rango para archivos estáticos, que se preparan previamente por un servicio especial. Ahora, quiero considerar las solicitudes de un back-end completo utilizando los mismos datos de mercado como ejemplo, y para las mismas velas, sin perder ganancias clave.
Entonces, ¿qué se planea lograr:
- Optimizar las solicitudes de back-end (reducir su número);
- Aumentar la velocidad de entrega de contenido al usuario final;
- Optimizar el tráfico.
Una vez más, enfatizo que la tecnología de rango es un estándar (
RFC 2616 ). Es compatible de forma nativa con los navegadores y pueden almacenar en caché las porciones de datos recibidas. Por lo tanto, la siguiente solicitud del navegador, si hay una memoria caché real de la parte solicitada, se implementa en el cliente sin molestar a sus servidores.
Si agrega
CDN entre el cliente y los servidores, puede obtener otra capa potente de almacenamiento en caché. Y si en el primer caso, el almacenamiento en caché ocurrirá para un cliente final específico, luego emparejado con un CDN, tendrá la oportunidad de almacenar datos en caché ya para un grupo de clientes finales.
Por lo tanto, para realizar una solicitud real al servidor, la solicitud debe superar dos niveles de almacenamiento en caché, cada uno de los cuales reduce el volumen de solicitudes al servidor de destino. Por supuesto, el "reducto" final, en la ruta de solicitud, puede ser su servidor con su caché.
De las características del uso de la tecnología de rango, debe tener en cuenta que funciona con porciones de bytes. Es decir con datos binarios Y podemos solicitar intervalos de bytes exactos. Deben responder, respectivamente, con un bloque binario.
Creo que lo suficientemente introductorio. Pasemos a un caso especial, y ya a modo de ejemplo, descubriremos cómo podemos usar toda esta "felicidad" en un problema particular: solicitar velas para un intervalo determinado con una exposición determinada.
Para empezar, como Necesitamos trabajar con estructuras binarias, codifiquemos nuestra vela. Para esto tomamos, por ejemplo, la siguiente estructura:
moment: int32 // min: float64 // max: float64 // open: float64 // close: float64 // volume: float64 // average: float64 //
Por lo tanto, nuestra estructura ocupará 52 bytes. Lo tomamos como un cuanto: el bloque binario mínimo.
A continuación, implementamos un controlador que aceptará solicitudes GET y analizará el encabezado del rango. En este caso, traduciremos el intervalo solicitado a cuantos por división simple sin resto, es decir por ejemplo, una solicitud de intervalo:
Range: 5200-52000Debemos interpretar en la dimensión de nuestro cuanto como:
Range: 100-1000En esencia, este será el desplazamiento y el límite de nuestra consulta de base de datos.
Con la definición de exposición es muy simple, podemos ponerla en la url. Por ejemplo:
/api/v1/candles/7mEs decir solicitaremos velas con una exposición de 7 minutos. Naturalmente, suponemos que este parámetro se puede cambiar a petición de la interfaz.
Ahora, conociendo la exposición requerida, el número de la primera vela y el número de la última vela que solicita la interfaz, podemos ejecutar la consulta correspondiente a la base de datos.
En general, recuerda mucho el clásico problema de paginación.
Quedan pequeñas cosas. Cada línea del resultado de la consulta se convierte en una estructura binaria (el mismo cuanto) y la matriz binaria resultante se muestra como el resultado de la consulta, y el rango de contenido se devuelve al encabezado de respuesta:
Content-Range: [ ] / [[ ] * [ ]]Para Pero, ¿cómo puede solicitar el frente el intervalo de tiempo deseado, e incluso en el intervalo de bytes? ¿Cómo sabe él algún número de vela allí? Aquí, también, todo fue inventado. El rango admite desplazamiento relativo, p.
Range: -52Solicite 52 bytes desde el final. Es decir La última vela. Ahora, conociendo el último momento de la última vela, sabiendo, a partir de la respuesta, el tamaño total del "archivo", puede calcular el número total de velas, y desde aquí determinar el intervalo de bytes para solicitar la exposición de tiempo deseada.
Si de repente quisiste hacer una pregunta, ¿por qué tantas dificultades? Por favor regrese a sus objetivos. Esta tecnología "enmascaró" las consultas analíticas de la base de datos en archivos binarios para el CDN y el navegador. Esto le permite transferir la mayoría de las solicitudes repetidas al CDN y al cliente final.
Quizás surja otra pregunta: ¿por qué no utilizar el almacenamiento en caché simple de las solicitudes GET? Bueno Vamos a hacerlo bien. Si ejecutamos dicha solicitud en REST clásico:
GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018Obtendremos un caché único para esta solicitud. Al ejecutar la siguiente consulta:
GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018Obtendremos otro caché único ... aunque, tenga en cuenta, la segunda solicitud solicita los datos incluidos en la respuesta de la primera.
Entonces, en el caso de la implementación propuesta arriba (rango), la segunda solicitud no formará un caché separado, sino que utilizará los datos ya recibidos de la primera solicitud. Y no entrará en el servidor. Y esto, ahorrando el tamaño de cachés y reduciendo el número de llamadas al servidor.
¿Hay alguna desventaja en esta tecnología? Si Son obvios:
- Esta tecnología no es adecuada para el cambio de datos a lo largo del tiempo, ya que basado en el almacenamiento en caché total.
- CDN CloudFlare solo almacena en caché los archivos por completo. Esto significa que si el cliente final solicita un intervalo de, por ejemplo, 1 a 100 bytes, CloudFlare realmente solicitará el archivo completo del servidor. Es decir en nuestro caso, cargará todas las velas con una cierta exposición. Lo pondrá solo y ya lo distribuirá él mismo. Esto incluso podría considerarse una ventaja, si no fuera por las restricciones en el lugar. Y si puede formar respuestas "pesadas" y muchos parámetros, entonces ... En general, está claro que el lugar terminará. Quizás no pudimos configurarlo correctamente. Pero hasta ahora el resultado es el siguiente.
- Se requiere para administrar las cachés con prudencia. Existen mecanismos suficientes para esto, pero requieren ajuste.
- El frontend debería poder analizar datos binarios y tener un conjunto de datos a bordo para trabajar con las solicitudes de rango.
Formularía la viabilidad de implementar esta estrategia de la siguiente manera: cuando lo necesite, lo comprenderá. Si ahora hay dudas, es útil saber sobre ella, pero no te molestes.