Cuando se introdujo el proyecto Redis qué cache distribuida, se enfrentará a este problema:
- ¿Qué datos se debe colocar en la memoria caché? Sobre qué base?
- los datos en caché se actualiza con el activo o expiró automáticamente expira?
- Si caducado caducará automáticamente, entonces el tiempo de caducidad de la forma de desarrollar?
Sólo dos semanas nos hacen un proyecto relacionado con la evaluación, el registro de proceso y la participación social; de utilizado por supuesto en el proceso de una gran cantidad de "torpe" si usted tiene una mejor manera, espero compartir.
01
Antecedentes del proyecto
Nuestro proyecto es una plataforma de servicio puro, que es el único servicio que proporciona una interfaz, y no hay página de operación, la interfaz llama cantidad diaria del proyecto es de aproximadamente 200 millones de veces, el pico de 10 millones tendrá éxito, porque la mayor parte de la interfaz es para el sistema interno , de modo más solicitado concentrado en el 09:00-21:00 de lunes a viernes, QPS cuando el pico del sistema entre 300-400.
Debido a que almacenamos los datos del proyecto usando MongoDB, en teoría, el apoyo QPS esta magnitud debería ser más que suficiente, pero tengo algunas observaciones y considerar así:
Aunque la integración de MongoDB es buenos datos, pero muchas escenas no son sola consulta, exagerada cuando una interfaz puede devolver cientos de piezas de datos, paquetes de referencia traseras tienen más de veinte mil líneas (no preguntar a mí, no se puede paginar en el retorno .. .... decirle claramente no);
- Aunque la integración de MongoDB es buenos datos, pero muchas escenas no son sola consulta, exagerada cuando una interfaz puede devolver cientos de piezas de datos, paquetes de referencia traseras tienen más de veinte mil líneas (no preguntar a mí, no se puede paginar en el retorno .. .... decirle claramente no);
- 99,95% del proyecto actual, el tiempo de respuesta de la interfaz de decenas a cientos de milisegundos, para satisfacer las necesidades básicas de la empresa, pero hay todavía un 0,05% son en respuesta a las solicitudes de más de 1s, en ocasiones incluso llegar a 5s, 10s;
- En cuanto a éstos desde hace mucho tiempo la respuesta de la solicitud, la mayor parte del tiempo consumido por la consulta MongoDB, pero cuando me volvería a solicitar el mensaje de forma manual cuando la interfaz de llamada de nuevo, todavía retorno milisegundos; MongoDB configuración en general, siempre han actualizado los datos, y he observado, tiempo de respuesta largo de estas interfaces, solicitando que punto en el tiempo cantidad particularmente grande;
- La razón de vez en cuando MongoDB consulta lenta confirmo que yo era la razón por la que puedo pensar, como por ejemplo: un gran número de operaciones de escritura afecta a la operación de lectura, tabla de bloqueo, el índice es menor que el tamaño de la memoria, etc., siendo que es el momento en que MongoDB presión; I observado, estas interfaces de tiempo de respuesta es largo, el punto de tiempo que un particularmente gran volumen de solicitudes, no se analiza específicamente aquí.
A pesar de que la solicitud sólo diez mil veces cuatro o cinco veces el tiempo de respuesta de una excepción, pero a medida que más y más acceso al elemento solicitado, cambio cualitativo cuantitativo después de que Paul falta, todavía tratan de crisis estrangulado en la cuna, tan decisivamente en la distribución de Redis hacer el almacenamiento en caché.
02
interfaz de peinado
El siguiente paso es la elaboración de estadísticas ambientales y resolver las interfaces para determinar qué interfaces se pueden colocar en la memoria caché, por lo que primero debemos tener una estadísticas en bruto para cada interfaz a los volúmenes de llamadas, porque no hay una plataforma de registro de acceso existente, por lo que utiliza la forma más estúpida, una serie de cosas de una interfaz.
- Un día el registro de jornada de trabajo se bajó, nuestros cuatro servidores de aplicaciones, registro diario sobre una G, bien bien;
- [Buscar en archivos] EditPlus través de esta función herramienta para encontrar el volumen de llamadas al día de cada interfaz, la interfaz ha sido en la línea 30, se ha dado cuenta de unos minutos, ya que es un trabajo de una sola vez, simplemente para contar manualmente;
- Varias veces al día puede no interfaz de sintonizar directamente ignorado, que, básicamente, sólo hay que poner millones de dólares para las interfaces diarias volumen de llamadas a la estancia, el siguiente paso del análisis.
03
Datos de la tabla de diccionario, la configuración de la clase
Este tipo de información es la más conveniente en la memoria caché, porque después de la frecuencia de actualización es particularmente baja, e incluso a veces inserto a'll sea ninguna actualización, si tales datos es mayor que la llamada que está seguro de poner en Redis de;
En cuanto a la estrategia de almacenamiento en caché, puede duplicar el tiempo para escribir y actualizar la base de datos Redis, modo de fallo automática también se puede utilizar, por supuesto, el tiempo de expiración puede ser más largo que poner un número, para nuestro proyecto, he utilizado la mitad de la estrategia unificada noche 12:00 fallado, el primero de estos datos, ya que nuestro sistema está extrayendo durante la noche por ETL, la sincronización de una vez al día, y la segunda es que no tenemos miedo de caché avalancha, tanto tráfico no por la noche, pero no hay acceso a la cantidad.
04
los datos hotspot los datos claramente
Hay una clase de datos, es evidente que los datos calientes;
Tenemos una interfaz, aunque los datos de negocio, la cantidad de datos, pero sólo unos pocos miles, pero las llamadas por día cerca de 400.000, y la frecuencia de actualización no es muy alta, tales datos Redis poner en ella, pero en ese momento ; como para qué política de caché, pero también de otros sistemas debido a que la sincronización de datos a través, de acuerdo con la sincronización de datos de tiempo, que finalmente adoptó un tiempo de expiración de una hora.
05
La evaluación de los datos restantes
De hecho, los dos primeros datos fácilmente pueden evaluarla, la clave es evaluar estos datos:
- Tenemos un volumen de llamadas al día interfaces de 200.000 a 300.000, no cantidad, pero las consultas más complejas y la lógica de procesamiento;
- La base de la cantidad de datos es demasiado grande como para poner todos los datos en una Redis en;
- No los datos subyacentes directamente en Redis porque hay múltiples dimensiones de consulta (condición);
- No se puede determinar la frecuencia de cada llamada de datos es la forma más pesimista resultado, cada llamada de datos una sola vez ese día, así que no hay necesidad de que el caché.
Pero no podemos decir que un trasiego nuestro cerebro: "el volumen de llamadas cada vez más grande, directamente en Redis en ella," o "mala evaluación, olvídalo, no poner el caché", y tomar una decisión todavía tiene que tener ninguna base , por lo que hago esto:
Paso 1.
Todas las interfaces para registrar todos los días para averiguar
Decenas ciertamente no es un archivo de registro de una vez, o para escribir sus propios programas para escoger los datos necesarios, pero teniendo en cuenta este trabajo sólo se puede hacer una vez, sigo tratando de ahorrar algo de tiempo.
EditPlus siguen utilizando esta herramienta [Buscar en archivos] función en la consulta cuadro Resultados [] copiar todo el contenido, se tardó dos minutos para poner 240 000 de registro para averiguarlo.
o La interfaz de datos de consulta 240 000
Paso 2.
Para importar datos en una base de datos para su posterior análisis
Cada registro de algo como esto:
XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.类名 : 请求参数:args1={"字段1":"XXX","字段2":"YYY"}
Registro que sólo necesitan tres elementos: solicitud de paquetes de campo 1 y campo 2, y el tiempo de llamada; cómo escogemos? Escribir un programa? Por supuesto, no hay problema, pero yo soy vago de esa manera, a pocos minutos pueden hacer cosas qué decenas de gasto de minutos, entonces? Y este es un trabajo de una sola vez, por lo que:
- Alternativamente totalidad: [17.03.2020] sustituir [/ t2020-3-17], es decir, para añadir una marca de tiempo en frente de la lengüeta;
- Alternativamente totalidad: [{ "Campo 1": "] sustituir [/ t];
- Alternativamente totalidad: [ "" Campo 2 ":"] en lugar de [/ t];
- Alternativamente totalidad: [ "}] Alternativamente a [], se sustituye con un nulo;
- Seleccione copiar, pegar para sobresalir en, sobresalir en la pestaña columna de intercambio de forma automática;
- Eliminar columnas innecesarias, dejando sólo los contenidos de campo del campo 1 y 2, y un sello de tiempo;
No se necesita unos pocos pasos de un minuto.
o dividir de cada tres campos del registro
Paso 3.
análisis de frecuencia de llamada
Al introducir datos en una base de datos para el análisis, de acuerdo con nuestras necesidades, nosotros queremos saber principalmente que los participantes no van a repetir la misma llamada? Cada llamada intervalo de tiempo? Un SQL get:
select 字段1 , 字段2, count(1) 调用次数, (MIDNIGHT_SECONDS(max(UPDATETIME)) - MIDNIGHT_SECONDS(min(UPDATETIME)))/60 调用间隔时间，处理成了分钟from TABLEgroup by 字段1 , 字段2having count(1) > 2with ur ;
Por supuesto, las estadísticas de llamadas intervalo, donde inexactitudes estadísticos, en concreto yo no explican, le química fina ...
En resumen, la cantidad de 240.000 llamadas al día, de los cuales 100 000 llamadas de una vez, 140.000 datos serán llamados repetidamente en un corto período de tiempo, incluso hay algunos datos se repite decenas de veces en la consulta en pocos minutos, por lo que esta interfaz Redis es más adecuado para poner en.
Etapa 4.
¿Cómo se almacenan los datos?
Permítanme decir que salvar lo que el formato de datos a los Redis, una imagen vale más que mil palabras:
o guardar el resultado del procesamiento a los Redis
En cuanto a la actualización de la política de caché Bueno, todavía usa para programar el tiempo de caducidad, de acuerdo con las estadísticas de tiempo de sincronización de datos y llamadas, este conjunto tiempo de 15 minutos más apropiadas.
Se puede ver en este proceso de evaluación, todas mis operaciones han mantenido una "lata vago perezoso" los hábitos buenos y mantener la productividad, hacer un buen uso de las herramientas, el ahorro de tiempo innecesario, todo el proceso tomó dos horas, la mayoría de las veces en la importación de datos, con casi media hora, pero afortunadamente, en este proceso, que pueda hacer otro trabajo.
Fuente: Webmaster Noticias