Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Centro de ayuda/ Distributed Cache Service/ Preguntas frecuentes/ Análisis de claves grandes, análisis de claves de mucho uso y escaneo de claves caducadas/ ¿Cómo puedo evitar las claves grandes y las claves de mucho uso?
Actualización más reciente 2023-05-08 GMT+08:00
Ver PDF
Compartir

¿Cómo puedo evitar las claves grandes y las claves de mucho uso?

  • Mantenga el tamaño de las cadenas dentro de los 10 KB y la cantidad de Hashes, Lists, Sets o Zsets dentro de los 5000.
  • Al nombrar claves, utilice la abreviatura del nombre del servicio como prefijo y no utilice caracteres especiales como espacios, frenos de línea, comillas simples o dobles y otros caracteres de escape.
  • No confíe demasiado en las transacciones de Redis.
  • El rendimiento de las conexiones cortas es pobre. Utilice clientes con los grupos de conexiones.
  • No habilite la persistencia de datos si utiliza Redis solo para el almacenamiento en caché y puede tolerar las pérdidas de datos.
  • Para obtener más información sobre cómo optimizar las claves grandes y las claves de mucho uso, consulte la tabla siguiente.

Categoría

Método

Clave grande

Dividir las claves grandes.

Escenarios:

  • Si la clave grande es una String, puede dividirla en varios pares de clave-valor y usar MGET o una canalización que consiste en varias operaciones de GET para obtener los valores. De esta manera, se puede dividir la presión de una única operación. Para un ejemplo de grupo, la presión de operación puede distribuirse uniformemente a múltiples particiones, reduciendo el impacto en una sola partición.
  • Si la clave grande contiene varios conceptos y tienen que operarse juntos, la clave grande no se puede dividir. Puede quitar la clave grande de Redis y almacenarla en otros medios de almacenamiento en su lugar. Este escenario debe ser evitado por el diseño.
  • Si la clave grande contiene varios conceptos, y solo se operan algunos conceptos cada vez, separe los conceptos. Tome una clave Hash como ejemplo. Cada vez que ejecuta el comando HGET o HSET, el resultado del módulo de valor hash N (personalizado en el cliente) determina en qué clave cae el campo. Este algoritmo es similar al utilizado para calcular las ranuras en Clúster Redis.

Almacenar las claves grandes en otros medios de almacenamiento.

Si una clave grande no se puede dividir, no es adecuada para ser almacenada en Redis. Puede almacenarlo en otros medios de almacenamiento, como SFS u otras bases de datos de NoSQL, y eliminar la clave grande de Redis.

ATENCIÓN:

No utilice el comando DEL para eliminar las claves grandes. De lo contrario, Redis puede bloquearse o incluso puede producirse una conmutación principal/en espera.

Establecer la caducidad adecuada y eliminar los datos caducados con regularidad.

La expiración apropiada impide que los datos caducados permanezcan en Redis. Debido a que Redis está libre de perezosos, los datos caducados no se pueden eliminar a tiempo. Si esto ocurre, escanee las claves caducadas.

Clave de mucho uso

Dividir las solicitudes de lectura y de escritura.

Si se lee con frecuencia una clave de mucho uso, configure la separación de lectura/escritura en el cliente para reducir el impacto en el nodo principal. También puede agregar réplicas para cumplir con los requisitos de lectura, pero no puede haber demasiadas réplicas. En DCS, las réplicas replican datos del principal en paralelo. Las réplicas son independientes entre sí y el retardo de replicación es corto. Sin embargo, si hay un gran número de réplicas, el uso de CPU y la carga de red en el nodo principal serán altas.

Utilizar la caché del cliente o la caché local.

Si sabe qué claves se utilizan con frecuencia, puede diseñar una arquitectura de caché de dos niveles (caché de cliente/local y Redis remoto). Los datos utilizados con frecuencia se obtienen en primer lugar de la caché local. La caché local y la caché remota se actualizan con escrituras de datos al mismo tiempo. De esta manera, la presión de lectura sobre los datos a los que se accede con frecuencia puede separarse. Este método es costoso porque requiere cambios en la arquitectura y el código del cliente.

Diseñar un interruptor o mecanismo de degradación.

Las claves de mucho uso pueden resultar fácilmente en la ruptura de la caché. Durante las horas pico, las solicitudes se pasan a la base de datos de backend, causando avalancha de servicio. Para asegurar la disponibilidad, el sistema debe tener un interruptor o mecanismo de degradación para limitar el tráfico y degradar los servicios si se produce una avería.