Prefacio
Cuenta pública original: bigsai
Para la Web, el aumento del número de usuarios y visitas promueve en cierta medida el cambio y progreso de la tecnología y la arquitectura del proyecto. Puede haber algunas de las siguientes condiciones:
- La concurrencia de páginas y las visitas no son muchas, el
足以支撑propio desarrollo lógico del negocio de MySQL . De hecho, no se requiere almacenamiento en caché. Como máximo, las páginas estáticas se pueden almacenar en caché. - La concurrencia de la página ha aumentado significativamente, la base de datos está algo bajo presión y algunos datos se actualizan con menor frecuencia
反复被查询o velocidad de consulta较慢. Entonces puede considerar el uso de tecnología de almacenamiento en caché para optimizar. Los objetos de alto impacto se almacenan en la forma de clave-valor de Redis, por lo que si los datos son afectados, no es necesario que pasen por el ineficiente db. Encuentre datos de redis eficientes. - Por supuesto, también puede encontrar otros problemas. También puede aumentar la cantidad de simultaneidad del sistema mediante el almacenamiento en caché de páginas estáticas, la aceleración de CDN e incluso el equilibrio de carga. Aquí no hay presentación.
Las ideas de almacenamiento en caché están en todas partes
Empezamos a comprender el significado del almacenamiento en caché a partir de un problema de algoritmo.
Pregunta 1:
- Ingrese un número n (n <20), pregunte
n！;
Análisis 1 :
- Solo considere el algoritmo y no considere el problema del valor fuera de límites.
Por supuesto que lo sabemosn!=n * (n-1) * (n-2) * ... * 1= n * (n-1)!,
entonces podemos resolver el problema con una función recursiva.
static long jiecheng(int n)
{
if(n==1||n==0)return 1;
else {
return n*jiecheng(n-1);
}
}De esta manera, cada solicitud de entrada debe ejecutarse nveces.
Pregunta 2:
- Ingrese t grupos de datos (tal vez cientos o miles), una xi para cada grupo (xi <20), encuentre
xi！;
Análisis 2 :
- Si usa
递归, ingrese t grupos de datos, cada vez que la entrada sea xi, entonces el número de veces que se ejecutará cada vez es:
cada vez que la entrada Xi sea demasiado grande o t sea demasiado grande , ¡ causará mucha carga! La complejidad del tiempo es O (n2) - Entonces, ¿puedes cambiar de opinión? Si, si
打表. La tabulación se usa a menudo en el algoritmo ACM, a menudo se usa para resolver los problemas de múltiples conjuntos de entrada y salida, resultados de búsqueda de teoría de grafos y almacenamiento de ruta. Entonces, encuentre el factorial para esto. Solo necesitamos solicitar una matriz, almacenar el número requerido en la matriz de acuerdo con el número de adelante hacia atrás, y generar el valor de la matriz directamente cuando lo obtenga más tarde. La idea es clara:
import java.util.Scanner;
public class test {
public static void main(String[] args) {
// TODO Auto-generated method stub
Scanner sc=new Scanner(System.in);
int t=sc.nextInt();
long jiecheng[]=new long[21];
jiecheng[0]=1;
for(int i=1;i<21;i++)
{
jiecheng[i]=jiecheng[i-1]*i;
}
for(int i=0;i<t;i++) {
int x=sc.nextInt();
System.out.println(jiecheng[x]);
}
}
}- La complejidad del tiempo es solo O (n) . El pensamiento aquí es
缓存similar al pensamiento. Primero almacene los datos en la matriz jiecheng [21]. Realice un cálculo. Si continúa accediendo más tarde, equivale a solicitar valores de matriz estática. Cada vez es O (1 operación).
Escenarios de aplicación de almacenamiento en caché
El almacenamiento en caché es adecuado para escenarios de alta concurrencia para aumentar la capacidad del servicio. Principalmente, guarde 经常被访问的数据o consulte 成本较高desde medios lentos a medios más rápidos, como desde 硬盘-> 内存. Sabemos que la mayoría de las bases de datos relacionales lo son 基于硬盘读写, y su eficiencia y recursos son limitados, mientras que redis se basa en memoria y sus velocidades de lectura y escritura varían mucho. Cuando el rendimiento de una base de datos relacional con alta concurrencia llega a un cuello de botella, puede colocar estratégicamente los datos a los que se accede con frecuencia en Redis para aumentar el rendimiento y la concurrencia del sistema.
Para escenarios y sitios web comunes, las bases de datos relacionales pueden ser lentas en dos lugares principales:
- Rendimiento de E / S de lectura y escritura deficiente
- Un dato puede calcularse por una cantidad mayor
Por lo tanto, el uso de caché puede reducir la cantidad de IO de disco y la cantidad de cálculos en bases de datos relacionales. La velocidad de lectura rápida también se refleja en dos aspectos:
- Basado en la memoria, lectura y escritura más rápidas
- Utilice el algoritmo hash para localizar directamente el resultado sin cálculo
Entonces, para un sitio decente, algo del tamaño del sitio, está almacenado en caché necessary, y Redis es sin duda una de las mejores opciones.
Necesito prestar atención a
El uso inadecuado de la caché puede causar muchos problemas. Por lo tanto, algunos detalles deben considerarse y diseñarse cuidadosamente. Por supuesto, la consistencia de datos más rara se analiza por separado a continuación.
Ya sea para usar caché
Los proyectos no pueden usar la caché por el simple hecho de almacenar en caché. La caché no es necesariamente adecuada para todos los escenarios. Si la consistencia de los datos es extremadamente alta , o los datos se cambian con frecuencia y no hay muchas consultas , o no hay simultaneidad en absoluto, la consulta no es necesariamente necesaria. El almacenamiento en caché también puede desperdiciar recursos, lo que hace que el proyecto sea inflado y difícil de mantener, y el uso del almacenamiento en caché de redis puede encontrar problemas de coherencia de datos que deben tenerse en cuenta.
Diseño de caché razonable
Al diseñar la caché, es muy probable que encuentre consultas de varias tablas. Si encuentra los pares clave-valor de la caché de consultas de varias tablas, debe considerarlo de manera racional. ¿Deben dividirse o combinarse? Por supuesto, si hay muchos tipos de combinaciones, pero no aparecen muchas con frecuencia, se pueden almacenar en caché directamente.El diseño específico debe basarse en las necesidades comerciales del proyecto y no existe un estándar muy absoluto.
Selección de estrategia de vencimiento
- La caché contiene datos relativamente activos y de uso común, y los recursos de Redis también son limitados. Debe elegir una estrategia razonable para eliminar la caché después de su vencimiento. Hemos aprendido
操作系统y sabido que existen algoritmos de primero en entrar, primero en salir ( FIFO ) en la implementación de la caché de la computadora ; el algoritmo de uso menos reciente ( LRU ); el mejor algoritmo de eliminación ( OPT ); el algoritmo de acceso mínimo a la página ( LFR ) y otros algoritmos de programación de disco. También puede aprender al diseñar la caché de Redis. FIFO basado en el tiempo es la mejor implementación. Y Redis全局keyrespalda la estrategia de vencimiento. - Y el tiempo de caducidad debe establecerse razonablemente de acuerdo con la situación del sistema. Si el hardware es mejor, puede ser un poco más largo, pero el tiempo de caducidad puede no ser bueno si es demasiado largo o demasiado corto. Si es demasiado corto, la tasa de aciertos de caché puede no ser alta y demasiado larga puede causar Una gran cantidad de datos impopulares se almacenan en Redis y no se publican.
Problemas de coherencia de datos ★
De hecho, los problemas de coherencia de datos mencionados anteriormente. Si los requisitos de coherencia son extremadamente altos, no se recomienda el almacenamiento en caché. Ordenemos un poco los datos en caché.
Los problemas de coherencia de datos se encuentran a menudo en la caché de Redis. Para un caché, a continuación se enumeran varias situaciones:
leer
read: Leer de Redis. Si no está en Redis, actualice la caché de Redis desde MySQL.
El siguiente diagrama de flujo describe la escena general, no hay disputa:
Escriba 1: actualice la base de datos primero, luego actualice el caché (simultaneidad baja normal)
Actualice la información de la base de datos y luego actualice la caché de Redis. Esta es una práctica común, la caché se basa en la base de datos y se toma de la base de datos.
Sin embargo, pueden surgir algunos problemas. Por ejemplo, si la caché de actualización falla (tiempo de inactividad y otras condiciones), la base de datos y los datos de Redis serán inconsistentes. Cree nuevos datos en la base de datos y almacene en caché los datos antiguos .
Escriba 2: elimine el caché primero y luego escriba en la base de datos (optimización de baja concurrencia)
problema resuelto
Esta situación puede evitar eficazmente el problema de evitar escribir en Redis por escrito 1 . Elimina la caché para actualizar. Lo ideal es hacer que la próxima visita a Redis vacíe a MySQL para obtener el último valor en la caché. Sin embargo, esta situación se limita a escenarios de baja concurrencia y no se aplica a escenarios de alta concurrencia.
El problema
Sin embargo, escriba 2 看似写入Redis异常的问题. Parece ser una mejor solución, pero todavía hay problemas en las soluciones de alta concurrencia. Discutimos en el escrito 1 que si la biblioteca de actualización es exitosa, la falla de actualización de la caché causará datos sucios. Nuestro ideal es borrar la caché para que el 下一个线程acceso sea adecuado para actualizar la caché. La pregunta es: ¿Qué pasa si este próximo hilo llega demasiado pronto, por coincidencia ?
Debido al subproceso múltiple, no sabe quién va primero, quién es más rápido y quién es más lento. Como se muestra en la figura anterior, habrá inconsistencias entre los datos de caché de Redis y MySQL. Por supuesto que puedes hacer la clave 上锁. Pero los bloqueos, algo tan pesado, tienen demasiada influencia en la concurrencia, ¡así que no los use sin bloquear! La situación anterior seguirá causando que la caché sea datos antiguos y la base de datos para datos nuevos con alta concurrencia . Y si la caché no caduca, este problema siempre existirá.
Escritura 3: Retraso de la estrategia de doble eliminación
Esta es la estrategia de doble eliminación retardada, que puede aliviar la inconsistencia entre la caché de Redis y los datos de MySQL causada por la entrada de hilos de lectura en el proceso de actualización de MySQL en Write 2 . El método es eliminar el caché -> actualizar el caché -> demora (unos cientos de ms) (de forma asincrónica) para eliminar el caché nuevamente . Incluso si el problema de escritura 2 ocurre en medio de la actualización de la caché . Causar inconsistencia de datos, pero el retraso (específicamente, dependiendo del negocio, generalmente varios cientos de ms) borrar nuevamente puede resolver rápidamente la inconsistencia.
Sin embargo, la solución de solo escritura en realidad tiene lagunas, como el segundo error de eliminación, la presión sobre el acceso a MySQL en condiciones de alta concurrencia, etc. Por supuesto, puede optar por utilizar colas de mensajes como MQ para resolver de forma asincrónica. De hecho, la solución real es difícil de tener en cuenta a toda prueba, por lo que se pueden rociar muchos peces gordos debido a algunos defectos en el diseño. Como autor de Caicai, no quiero mostrar tu fealdad aquí. Todos agradecen tus contribuciones.
Escriba 4: manipule directamente la caché y escriba en SQL con regularidad (adecuado para alta concurrencia)
Cuando se 一堆并发(写)lanza algo, es difícil brindar a los usuarios una experiencia cómoda incluso si los esquemas anteriores usan comunicación asíncrona en cola de mensajes. Y la operación a gran escala de SQL también causará una presión considerable en el sistema. Entonces, otra solución es manipular directamente el caché y escribir el caché en SQL periódicamente. Debido a que Redis, una base de datos no relacional, se basa en operaciones de memoria, KV es mucho más rápido que las bases de datos relacionales tradicionales.
Lo anterior es adecuado para el diseño de negocios en situaciones de alta concurrencia. En este momento, los datos de Redis son el pilar y los datos de MySQL son los auxiliares. Insértelo regularmente (como una biblioteca de respaldo de datos). Por supuesto, este tipo de alta concurrencia a menudo tiene diferentes requisitos debido a pares de negocios 读, 写orden, etc., y puede tener que usar 消息队列y 锁completar la incertidumbre e inconsistencia causadas por la alta concurrencia y el multiproceso. Estabilidad, mejora la confiabilidad empresarial.
En resumen, cada 高并发vez 数据一致性要求高se necesita más la solución adecuada 考虑和顾及en el diseño de la coherencia de los datos 越复杂、越多. Lo anterior también es el aprendizaje del autor y el aprendizaje de auto-divergencia (sin sentido) para los problemas de coherencia de datos de Redis. Si hay una explicación irrazonable, ¡corrígeme!
Por último, si se siente bien, haga clic en tres enlaces. Bienvenido a prestar atención a la cuenta pública original: " bigsai ". Aquí, no solo puede aprender conocimientos y productos secos, sino también preparar mucha información avanzada para usted. Simplemente responda a la contraseña "bigsai". ¡recibir!
