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

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.

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.