Con el fin de mejorar el rendimiento del sistema, a menudo nos introducimos buffer de la capa de la arquitectura de negocio.
- la penetración de la caché
- Una colección de almacenamiento en caché
- caché de datos en caliente
- Uso traba para asegurar una alta consistencia
- estrategia optimista
- Rebautizar
- Generar claves temporales
- SortedSet
- latencia Queuing
- ventana deslizante
- Algo de sentido común
la penetración de la caché
Con el fin de evitar que los datos no válidos ocupa la caché, no lo hacemos por lo general objeto vacío almacenado en la memoria caché, pero esta estrategia dará como resultado preguntas penetrantes caché.
Para consultar los datos que no existe, entonces, por supuesto, esto no se puede encontrar en los datos de la caché, la invalidación de caché que es el acceso lógico a la base de datos, todos los datos que no existe consulta la base de datos va a llegar, un fenómeno conocido como la penetración de caché.
Con el fin de reducir el acceso de base de datos sin sentido, podemos almacenar en caché los datos no indica la presencia de un marcador de posición.
En comparación con una mayor probabilidad de acceso que el acceso a datos nunca ha existido borrado de datos, datos de borrado y por lo tanto debe ser colocado en la representación caché ha sido eliminado marcador de posición.
Una colección de almacenamiento en caché
Redis ofrece la lista, Hash, Set y SortedSet y otras estructuras de datos, que llamaremos una colección de almacenamiento en caché.
Montaje de caché se actualiza normalmente una lógica más compleja (o difícil de garantizar la coherencia) y la lógica de la reconstrucción es simple, pero para reconstruir la base de datos de caché también puede traer una gran cantidad de presión.
Contador de actualización de la lógica también tiene un complejo de almacenamiento en caché, pero simple a reconstruir para reconstruir las características de presión de bases de datos de caché, los autores también pueden clasificar como una colección de almacenamiento en caché. La complejidad del contador cuando el objeto es la máquina de estado especialmente compleja, como un recuento del número de usuarios y el número total de artículos da a conocer artículos.
En una lista de los artículos de revisión, por ejemplo, cuando Redis caché revisar la lista está vacía, hay dos posibles razones:
- invalidación de caché
- No hace comentarios
Si no se encuentra la memoria caché en la lista de comentarios después del comentario al intentar actualizar la memoria caché, debemos tener en cuenta es un error de caché o el original no hizo ningún comentario. No utilice LPUSH directa o instrucción Zadd insertar un comentario.
Montaje de elementos de la caché debe ser objetos u objetos de identificación inmutable . Aún revisar la lista, por ejemplo, si el almacenamiento serializado comentario o un objeto directamente en la lista SortedSet, sólo conoce los objetos de campo completo con el fin de localizar el comentario. Después de modificar un comentario, no podemos conseguir una posición más alta o modificar el contenido del comentario dificultad inicial. Si existe un comentario en la pluralidad de conjuntos de almacenamiento en caché, se necesita modificar múltiple.
Además, el objeto completo es mucho mayor que el número de bytes de identificación comentarios, utilice el ID cuando se necesita almacenamiento múltiple puede ahorrar una gran cantidad de memoria.
caché de datos en caliente
En el negocio de bienes, a menudo necesitamos para hacer frente a los problemas de invalidación de caché de datos de punto de acceso. cantidad punto de acceso de lectura simultánea de datos es grande, puede haber un fallo se produce una vez que el caché de gran número de subprocesos tienen acceso a la base de datos, puede incluso ralentizar el tiempo de inactividad de la base de datos de respuesta y otras consecuencias graves.
datos con frecuencia escritas en caliente pueden ocurrir en algunos escenarios, utilizando la política de caché actualizada no suele ser un problema. Si elegimos eliminar estrategia de caché caducado ser actualizado, porque la actualización de datos en caliente conduce muy rápidamente a borrar la memoria caché con frecuencia producen grandes cantidades de invalidación de caché más errores. Si se utiliza una estrategia de actualización de la base de datos después de la primera borrar la memoria caché, un gran número de solicitudes de lectura será muy probablemente resultaría en datos obsoletos en los errores de concurrencia de caché de escritura.
Si los datos de puntos calientes tales como Set o SortedSet conjunto de almacenamiento en caché, es posible que no pueda utilizar un atómicas instrucciones para completar la operación de reconstrucción, y por lo tanto deben tenerse en cuenta para garantizar la seguridad de los subprocesos del proceso de reconstrucción.
Dependiendo de los requisitos de consistencia de datos ¿Qué tan caliente, tenemos dos conjuntos de políticas.
Uso traba para asegurar una alta consistencia
Para las escenas de alto requerimiento de consistencia podemos utilizar el servicio de bloqueo distribuido. Para acceder a los datos después de la petición de lectura debe obtener un bloqueo de lectura, escribir una solicitud para actualizar los datos deben ser obtenidos después de un bloqueo de escritura.
Cuando se produce el caso de un fallo de caché, el servicio de bloqueo distribuido se asegurará de que hay uno y sólo un hilo a bloqueos de escritura adquirir y hacer caché de los trabajos de reconstrucción de lectura, leer otros temas debido a la imposibilidad de obtener un bloqueo está bloqueada hasta que la caché de reconstrucción se ha completado. Este método evita el gran número de hilos de repetir el resultado base de datos de caché de la reconstrucción de la presión del trabajo, pero no puede evitar la lenta respuesta.
En el patrón Singleton en varios subprocesos llamar simultáneamente getInstance () método puede conducir a duplicar objetos creados utilizando la reconstrucción de bloqueo caché hay problemas similares. Un hilo encontró un error de caché Así que un trabajo de reconstrucción bloqueo de escritura, hilo B se completa antes de acceder a la caché de reconstruir la invalidación de caché se sigue produciendo, luego pase intentos B para adquirir un bloqueo de escritura. Dado que el bloqueo de escritura está en manos de hilo A, el hilo B se bloquea hasta que finalice la regeneración de obtener un bloqueo de escritura. Debido a que la memoria caché se ha reconstruido, si hilo B continúa para reconstruir la caché resultará en sentido de arriba.
Singleton patrón estamos familiarizados con la estrategia de Check-Lock-Check para resolver este problema:
try {
读取缓存
加读锁
} finally {
释放读锁
}
if (缓存失效) {
try {
加写锁
读取缓存
if (缓存失效) {
重建缓存
}
} finally {
释放写锁
}
}
Debido a los problemas de seguridad de rosca de bloqueo de protección contra escritura cuando hay que preocuparse por la reconstrucción de la memoria caché.
estrategia optimista
Cuando un fallo de caché de datos en caliente, se puede utilizar por primera vez el marcador de posición del marcador de posición y la reconstrucción luego en caché. Otros temas leen marcador de posición caché devolverá un resultado vacío sin acceso a la base de datos, sino también para evitar las consecuencias negativas de un gran número de secuencias de rosca pueden causar.
marcador de posición no garantiza que sólo un hilo para acceder a la base de datos. Cuando un hilo Un marcador de posición escrito, el subproceso B puede haber ocurrido un error de caché en el proceso de reconstrucción.
Si no podemos garantizar el proceso de reconstrucción atómica, se puede completar la operación de reconstrucción de una clave temporal, a continuación, utilizar el comando Cambiar nombre para reemplazar clave oficialmente abierta atómica a todas las roscas.
Rebautizar
Aunque los comandos Redis son atómicas, pero a menudo se encuentran con un solo comando no puede completar la operación, además de la utilización de bloqueo distribuido a proceso complejo de seguridad hilo de garantía, pero en algunos escenarios que pueden utilizar el comando de cambio de nombre para reducir la sobrecarga.
Un escenario típico es mencionado más arriba, no podemos garantizar la operación se puede hacer en una clave privada temporal cuando el subproceso actual caché reconstruir o actualizar las operaciones atómicas, y luego usar el comando Cambiar nombre para reemplazar clave oficialmente abierta atómica a todas las roscas.
Otro escenario común es los datos sucios en un conjunto o hash, el uso de comandos de forma asíncrona sscan o HSCAN actualizada. sscan comando sólo se garantiza para comenzar al final del recorrido clave en todo el proceso ha estado presente en el conjunto de datos serán devueltos al menos una vez, si es que atraviesa al mismo tiempo añadir nuevos datos podrían resultar en el caso de repetirse o desaparecidos.
Podemos conjuntos de datos sucios para cambiar el nombre de los hilos clave privada temporal asíncronos, hilo asíncrono al atravesar sucia conjunto de datos privada, otros hilos todavía puede añadir datos a la línea de conjuntos de datos sucios.
Generar claves temporales
En un entorno agrupado, sólo se puede apoyar comando RENAME y RENAMENX en la misma ranura. Por lo tanto, podemos utilizar mecanismos para asegurar HashKey clave temporal y la llave original en la misma ranura.
Si la llave original es el "original" Podemos generar una clave temporal es "{} -1 originales", mostrando los apoyos sólo por la subcadena dentro de las llaves es determinada ranura de hash, "{} -1 originales" y " originales "en la misma ranura.
El propósito de la clave temporal es para evitar problemas de concurrencia operan de un solo subproceso, así que asegúrese de comprobar si la clave ha sido ocupado temporalmente por otros hilos.
Hay dos estrategias temporales de generación de claves:
- llave original más un valor aleatorio: El "{} -kGi3X1 originales", la ventaja de este método es una baja probabilidad de azar violación clave, pero que es difícil de analizar con una base de datos de clave temporal
- llave original y contador: El "original, {} -1", "{} -2 originales", la ventaja de este método es fácil de clave temporal biblioteca de exploración, pero una probabilidad de colisión superior.
No existe después de la detección usando la clave temporal no es seguro, se detecta el hilo A entre la clave temporal disponible real utilizando la clave temporal, otros hilos que detectará cuando está disponible con una clave temporal.
Con el fin de evitar un conflicto clave temporal, podemos tratar primero de conjunto antes de usar un marcador de posición. Por ejemplo, el uso de "{ORIGINAL} -1" antes de la primera ejecución "SETNX {ORIGINAL} -1-lock" si tiene éxito, o se puede utilizar de forma segura "{ORIGINAL} -1". Que en la práctica es añadir un simple distribuida bloqueo.
El uso más valor aleatorio deben ser reconstruidos o caché actualizados para minimizar los conflictos. Utilizar el contador además deben atravesar los métodos sucios, podemos buscar una clave temporal no se libera bajo el mostrador para continuar recorriendo el proceso se interrumpe.
SortedSet
SortedSet Redis solamente como una estructura de datos se pueden ordenar y algunos pueden encontrar la gama de aplicaciones más flexibles.
latencia Queuing
La consistencia en la escena puede ser utilizado sin altos requisitos SortedSet actuar como una cola de retardo, el contenido del mensaje como un miembro, el tiempo de ejecución predeterminado, como una puntuación de marca de tiempo UNIX.
El método de la llamada de sondeo ZRANGEBYSCORE tiempo de ejecución predeterminado es anterior a la hora actual del mensaje y envía proceso Msg Consumidor.
127.0.0.1:6379> ZADD DelayQueue 155472822 msg
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE DelayQueue 0 1554728933 WITHSCORES
1) "msg"
2) "1554728822"
Debido al mecanismo de persistencia Redis, no podemos proporcionar ninguna alta consistencia del servicio sobre la base de la cola Redis.
No utilizar Redis hacer cola de mensajes a los requisitos de alta consistencia de la escena de negocios .
ventana deslizante
En tal búsqueda caliente o limitando tales escenarios de negocio que necesitamos para encontrar rápidamente las palabras clave más buscados en la última hora.
Del mismo modo la cola de demora, la palabra clave como un miembro de SortedSet, UNIX sello de tiempo son como puntuación.
Uso de comandos ZRANGEBYSCORE para consultar un determinado período de tiempo evento ocurrió, ZREMRANGEBYSCORE comando elimina los datos obsoletos.
Algo de sentido común
Leer los lectores de este artículo debe tener alguna experiencia con caché Redis, por lo que algunos conocimientos básicos en el pasado para evitar la pérdida de tiempo del lector.
- IO operación que consume normalmente es mucho más alta que las CPU calcula, en la medida de lo posible el uso de comandos por lotes o el mecanismo MGET Pipeline como a reducir el tiempo de IO, no leen y ciclos de escritura IO operación Redis
- modelo Redis el uso de kernel IO multiplexar el modo de hilo único, la ejecución del comando para garantizar la atomicidad y serialización. (Al escribir en Redis 4.0 versión es todavía el caso, entonces es posible introducir núcleo multi-roscado)
- Redis de RDB y AOF son el modo asíncrono persistente, no podemos garantizar que los datos no se pierde tras el colapso de Redis. Así que no Redis para requisitos de alta consistencia de la escena de negocios.