I. Introducción
En las aplicaciones de Internet, el almacenamiento en caché se ha convertido en un componente clave de la arquitectura de alta concurrencia. Este blog presenta principalmente los escenarios típicos de uso del almacenamiento en caché, análisis de casos prácticos, especificaciones de uso de Redis y monitoreo regular de Redis.
Dos, comparación de caché común
Las soluciones de almacenamiento en caché comunes incluyen el almacenamiento en caché local, incluidos HashMap / ConcurrentHashMap, Ehcache, Memcache, Guava Cache, etc., y el middleware de almacenamiento en caché, incluidos Redis, Tair, etc.
Tres escenarios de uso de Redis
1. contar
Redis implementa funciones rápidas de conteo y almacenamiento en caché.
Por ejemplo: el número de espectadores en línea de un video o transmisión en vivo aumentará en 1 cada vez que el usuario lo reproduzca.
2. Gestión centralizada de sesiones
La sesión se puede almacenar en el servicio de aplicaciones JVM, pero este tipo de solución tendrá problemas de coherencia y una alta concurrencia provocará un desbordamiento de la memoria de la JVM. Redis gestiona de forma centralizada la sesión del usuario, en este caso, siempre que se garantice la alta disponibilidad y escalabilidad de Redis, cada actualización de usuario o inicio de sesión de consulta obtendrá directamente la información de Redis.
3. Límite de velocidad
Por ejemplo: la empresa requiere que el usuario solo pueda obtener el código de verificación 5 veces en un minuto.
4. Tabla de clasificación
La velocidad de consulta de las bases de datos relacionales es generalmente lenta en la clasificación, por lo que puede usar SortedSet de redis para ordenar los datos calientes.
Por ejemplo, en un proyecto, si necesita contar la lista de clasificación de oro del ancla, puede usar la identificación del ancla como miembro y el valor de popularidad correspondiente al regalo de actividad recompensado ese día como puntuación. Puede obtener la lista diaria de actividad del ancla a través de zrangebyscore.
5. Cerradura distribuida
En escenarios reales de concurrencia multiproceso, los bloqueos distribuidos se utilizan para limitar la ejecución concurrente de programas. Se utiliza principalmente para evitar la ruptura de la memoria caché en escenarios de alta concurrencia.
Las cerraduras distribuidas están en realidad "ocupando el pozo". Cuando otro proceso ejecuta setnx, encuentra que la bandera ya es 1 y tiene que rendirse o esperar.
Cuatro, análisis de casos
1. [Caso] El comando de configuración de vencimiento eliminará el tiempo de vencimiento
Todas las estructuras de datos de Redis se pueden configurar para que caduquen. Si una cadena tiene un tiempo de vencimiento establecido y luego lo restablece, hará que el tiempo de vencimiento desaparezca. Por tanto, en el proyecto, es necesario evaluar razonablemente la capacidad de Redis para evitar el conjunto frecuente que provoca que no se produzca una estrategia de caducidad, lo que indirectamente provoca que la memoria se llene.
La siguiente es una captura de pantalla del código fuente de Redis:
2. [Caso] ERROR sobre la configuración de caducidad de Jedis 2.9.0 y versiones anteriores
Se descubrió que Jedis tenía un error al llamar al comando expiredAt. Finalmente se llamó al comando pexpire. Este error hará que la clave caduque durante mucho tiempo y provocará un desbordamiento de la memoria de Redis y otros problemas. Se recomienda actualizar a Jedis 2.9.1 y superior.
El código fuente de BinaryJedisCluster.java es el siguiente:
@Override
public Long pexpireAt(final byte[] key, final long millisecondsTimestamp) {
return new JedisClusterCommand<Long>(connectionHandler, maxAttempts) {
@Override
public Long execute(Jedis connection) {
return connection.pexpire(key, millisecondsTimestamp); //此处pexpire应该是pexpireAt
}
}.runBinary(key);
}Compare pexpire y pexpireAt:
Por ejemplo, la hora actual que estamos usando es 2018-06-14 17:00:00, y su marca de tiempo Unix es 1528966800000 milisegundos. Cuando usamos el comando PEXPIREAT, por ser una hora pasada, la clave correspondiente caducará inmediatamente.
Cuando hacemos un mal uso del comando PEXPIRE, la clave no caducará inmediatamente, pero caducará después de 1528966800000 milisegundos. El tiempo de caducidad de la clave será bastante largo, unos pocos W días después, lo que puede causar desbordamiento de la memoria de Redis, caída del servidor y otros problemas.
3. [Caso] La caché está penetrada
La clave en caché tiene una estrategia de caducidad. Si hay una gran cantidad de solicitudes simultáneas para esta clave en este momento, estas solicitudes generalmente devolverán los datos de origen de la base de datos de back-end y se restablecerán a la caché cuando la caché expire. En este momento, es posible que se produzcan grandes solicitudes simultáneas Presione hacia abajo la base de datos back-end instantáneamente.
Hay dos soluciones de optimización de uso común en la industria :
El primer tipo: utilizando bloqueos distribuidos para garantizar una alta concurrencia, solo un hilo puede regresar a la base de datos de back-end de origen.
El segundo tipo: para garantizar que la clave de Redis recibida por solicitudes de alta concurrencia sea siempre válida, utilice solicitudes de no usuarios para regresar al backend de origen y cambie al retorno activo al origen. Generalmente, las tareas asincrónicas se pueden usar para actualizar activamente la caché.
4. [Caso] La arquitectura independiente de Redis prohíbe el uso de bibliotecas distintas de cero
Redis ejecuta el comando seleccione 0 y seleccione 1 para cambiar, lo que provoca una pérdida de rendimiento.
RedisTemplate primero obtendrá el enlace al ejecutar el método de ejecución.
Ejecute en RedisConnectionUtils.java, habrá un método para obtener el enlace.
JedisConnectionFactory.java llamará al constructor JedisConnection. Tenga en cuenta que el dbIndex aquí es el número de la base de datos, como por ejemplo: 1
Continúe con el seguimiento del código JedisConnection, cuando la biblioteca de selección sea mayor que 1, habrá una operación de selección de base de datos. Si siempre usa la biblioteca 0, no necesita ejecutar comandos adicionales de la biblioteca de corte. Sabiendo cuál es el primer lugar para cortar seleccione 1 de la biblioteca, ¿de dónde vino el seleccione 0?
De hecho, el cliente usa Redis para liberar el enlace, pero RedisTemplate lo ha liberado automáticamente para nosotros, volvamos al lugar donde RedisTemplate ejecutó el método execute (...) al principio.
Lo siguiente es RedisConnectionUtils.java, que ejecuta el código para cerrar el enlace.
De acuerdo con los comentarios del código, si el número de biblioteca seleccionado no es 0, el marco spring-data-redis restablecerá la selección 0 cada vez.
En el negocio del centro comercial vivo, el rendimiento de la interfaz de la página de detalles del producto se ha optimizado más de 3 veces.
Verifique además que el cambio de base de datos afecta el rendimiento al menos unas 3 veces (según el negocio específico).
Rediscluster cluster database, default 0 database, no puede elegir otras bases de datos, lo que evita este problema.
5. [Caso] Tenga cuidado con la complejidad del tiempo o (n) comando Redis
Redis es de un solo subproceso, por lo que es seguro para subprocesos.
Redis utiliza E / S sin bloqueo y la complejidad de tiempo de la mayoría de los comandos es O (1).
El uso de comandos que consumen mucho tiempo es muy peligroso, ya que requerirá mucho tiempo de procesamiento en un solo hilo, lo que hará que todas las solicitudes se ralenticen.
Por ejemplo: Obtenga todos los elementos smembers myset en la colección de conjuntos, devuelva todos los miembros en el Hash especificado y la complejidad de tiempo es O (N).
El valor establecido en la caché aumenta. Cuando la interfaz de alto paralelismo solicita, los datos relevantes se leerán de Redis. El tiempo de lectura de cada solicitud se hace más largo y la superposición continua conduce a la situación de la LLAVE rápida y se bloquea un determinado fragmento de Redis. El uso de la CPU alcanzó el 100%.
6. [Caso] Tecla de acceso rápido de caché
En Redis, una tecla con una frecuencia de acceso alta se llama tecla de acceso rápido. Cuando una solicitud de una tecla de acceso rápido llega al host del servidor, la cantidad de solicitud es extremadamente grande, lo que resulta en recursos de host insuficientes e incluso tiempo de inactividad, lo que afecta los servicios normales.
Hay dos razones para el problema de las teclas de acceso rápido :
-
Los datos consumidos por los usuarios son mucho más grandes que los datos producidos, como productos de actualidad o flash, noticias de actualidad, reseñas de actualidad, etc. Estos escenarios típicos con más lectura y menos escritura causarán problemas de actualidad.
- La fragmentación de solicitudes está concentrada, superando el límite de rendimiento de un solo servidor, como una clave de nombre fijo, el hash cae en un servidor y la cantidad de visitas es extremadamente grande. Cuando se excede el límite del servidor, se producirá el problema de la tecla de acceso rápido.
Entonces, en los negocios reales, ¿cómo identificar la tecla de acceso rápido?
-
Según la experiencia empresarial, calcule cuáles son las teclas de acceso rápido;
-
Recopilación de estadísticas de clientes, estadísticas locales o informes;
- Si el servidor tiene una capa de agente, puede recopilarse y notificarse en la capa de agente;
Cuando reconocemos la tecla de acceso rápido, ¿cómo resolver el problema de la tecla de acceso rápido ?
-
Expansión del clúster de Redis: aumente las copias de fragmentos para equilibrar el tráfico de lectura;
-
Más hash de las teclas de acceso rápido, como hacer una copia de seguridad de una clave como key1, key2 ... keyN, N copias de seguridad de los mismos datos, N copias de seguridad distribuidas a diferentes fragmentos y acceso aleatorio a una de las N copias de seguridad durante el acceso, además Comparta el tráfico de lectura.
- Utilice la caché secundaria, es decir, la caché local.
Cuando se encuentra una tecla de acceso rápido, los datos correspondientes a la tecla de acceso rápido se cargan primero en la caché local del servidor de aplicaciones para reducir las solicitudes de lectura a Redis.
Cinco, especificación de Redis
1. Está prohibido usar una base de datos 0
Descripción:
La arquitectura independiente de Redis prohíbe el uso de otras bases de datos en Redis.
Razón:
Mantenga la compatibilidad para la futura migración empresarial Redis Cluster.
Cuando se cambian varias bases de datos con select, consume más recursos de CPU.
Es más fácil automatizar la gestión de operaciones y mantenimiento, por ejemplo, el comando scan / dbsize solo se utiliza como base de datos.
- Algunos clientes de Redis no admiten varias bases de datos de instancia única debido a problemas de seguridad de subprocesos.
2. Especificación de diseño clave
Asigne un nombre al prefijo de clave de acuerdo con la función comercial para evitar que se sobrescriban los conflictos de claves. Se recomienda utilizar dos puntos para separar, por ejemplo, nombre comercial: nombre de tabla: id :, como en vivo: rango: usuario: semanal: 1: 202003.
La longitud de la clave es inferior a 30 caracteres, el nombre de la clave en sí es un objeto String y Redis codifica la longitud máxima en 512 MB.
En el escenario de la caché de Redis, se recomienda establecer el valor TTL para todas las claves para garantizar que las claves que no se utilizan se puedan limpiar o eliminar a tiempo.
El diseño de teclas prohíbe la inclusión de caracteres especiales, como espacios, saltos de línea, comillas simples y dobles y otros caracteres de escape.
3. Especificación de diseño de valor
El tamaño de un solo valor debe controlarse dentro de los 10 KB y la cantidad de claves de instancia única es demasiado grande, lo que puede provocar la recuperación de claves caducadas a tiempo.
Para tipos de datos complejos, como set, hash y list, el número de elementos en la estructura de datos debe reducirse tanto como sea posible. Se recomienda que el número no exceda de 1000.
4. Preste atención a la complejidad del tiempo de comando
Se recomienda utilizar comandos O (1), como get scard.
El comando O (N) se centra en el número de N. Los siguientes comandos deben controlar el valor de N a nivel empresarial.
enorme
largo
huele
- zrange
Por ejemplo: la complejidad de tiempo del comando smember es O (n). Cuando n continúa aumentando, hará que la CPU de Redis continúe elevándose y bloquee la ejecución de otros comandos;
5. Uso del oleoducto
Descripción:
Pipeline es una forma de envío por lotes de Redis, es decir, se establecen varias operaciones de comando una vez y se envían a Redis para su ejecución, lo que tendrá un mejor rendimiento que el envío circular único.
El cliente de Redis ejecuta un comando en 4 procesos: enviar comando -> cola de comandos -> ejecución de comando -> devolver resultado.
Los comandos mget y mset de uso común ahorran efectivamente RTT (tiempo de ida y vuelta de ejecución de comandos), pero hgetall no tiene mhgetall y las operaciones por lotes no son compatibles. En este punto, debe usar el comando Pipeline
Por ejemplo: en el proyecto de transmisión en vivo, debe consultar las clasificaciones diarias, semanales y mensuales del presentador al mismo tiempo, usar PIPELINE para enviar varios comandos a la vez y devolver tres datos de clasificación al mismo tiempo.
6. Comando de desactivación en línea
- Prohibir el uso de Monitor
Está prohibido utilizar el comando monitor en el entorno de producción. En condiciones de alta concurrencia, el comando monitor tendrá el peligro oculto de explosión de la memoria y afectará el rendimiento de Redis.
- Prohibir el uso de llaves
La operación de las teclas es atravesar todas las teclas, si hay demasiadas teclas, la consulta lenta bloqueará otros comandos. Por lo tanto, las teclas y los comandos de patrón de teclas están prohibidas.
Se recomienda utilizar el comando de escaneo en línea en lugar del comando de teclas.
- Prohibir el uso de Flushall, Flushdb
Borre todos los registros en todas las bases de datos en Redis, y el comando es atómico y no terminará la ejecución. Una vez ejecutado, no fallará.
- Prohibir el uso de Save
Bloquee el servidor Redis actual hasta que se complete la operación de persistencia, lo que provocará un bloqueo a largo plazo para instancias con gran memoria.
- BGREWRITEAOF
AOF manual, la persistencia manual provocará un bloqueo a largo plazo para instancias con gran memoria.
- Config
Config es un método de configuración del cliente, que no favorece el funcionamiento ni el mantenimiento de Redis. Se recomienda configurarlo en el archivo de configuración de Redis.
Seis, monitoreo de Redis
1. Consulta lenta
Método 1: registro lento para obtener un registro de consultas lento
127.0.0.1: {puerto}> slowlog get 5
1) 1) (entero) 47
2) (número entero) 1533810300
3) (número entero) 175833
4) 1) "BORRAR"
2) "primavera: sesión: vencimientos: 1533810300000"
2) 1) (entero) 46
2) (número entero) 1533810300
3) (número entero) 117400
4) 1) "SMEMBERS"
Método 2: Se pueden monitorear consultas lentas más completas a través de las herramientas de CacheCloud.
Ruta: "Lista de aplicaciones" -haga clic en el nombre de la aplicación correspondiente- haga clic en la pestaña "Consulta lenta".
Haga clic en "Consulta lenta" para centrarse en la cantidad de consultas lentas y comandos relacionados.
2. Supervisar la tasa de uso del núcleo de la CPU vinculada a la instancia de Redis
Dado que Redis es de un solo subproceso, se centra en monitorear el uso del núcleo de la CPU vinculado a la instancia de Redis.
Por lo general, la tasa de utilización de recursos de la CPU es de aproximadamente el 10%. Si la tasa de utilización es superior al 20%, considere la posibilidad de utilizar la persistencia RDB.
3. Equilibrio de carga de fragmentos de Redis
El modelo actual de arquitectura de redis-cluster, un clúster compuesto por 3 maestros y 3 esclavos, presta atención al balance de tráfico de solicitudes para cada fragmento de Redis-cluster;
Obtenga por comando: redis-cli -p {puerto} -h {host} --stat
En general, se requiere una alarma para más de 12W.
4. Siga BigKey
A través de las herramientas proporcionadas por Redis, redis-cli escanea la clave de Redis correspondiente con regularidad para su optimización.
El comando específico es el siguiente: redis-cli -h 127.0.0.1 -p {puerto} --bigkeys o redis-memory-for-key -s {IP} -p {puerto} XXX_KEY
Generalmente, más de 10K es una clave grande en la que hay que centrarse. Se recomienda optimizar desde el nivel empresarial.
5. Supervisar la memoria ocupada por Redis
Vea el comando de memoria de información para evitar problemas de rendimiento causados por el agotamiento de MaxMemory asignado en escenarios de alta concurrencia.
Concéntrese en el valor correspondiente al elemento de configuración used_memory_human. Cuando el incremento es demasiado alto, se requiere centrarse en la evaluación.
Siete, resumen
La combinación de características comerciales específicas, la evaluación razonable de la capacidad de memoria requerida por Redis, la selección de tipos de datos y la configuración de tamaños de clave única pueden servir mejor a la empresa y brindar garantías de alto rendimiento para la empresa.
Autor: Jessica Chen