REDIS22_Especificaciones y sugerencias de desarrollo comunes

especificación-redis

• ①.Con respecto a las especificaciones de uso de pares clave-valor, hay dos aspectos principales:

1. Convenciones de nomenclatura de claves: Sólo las convenciones de nomenclatura pueden proporcionar claves que sean fácilmente legibles y fáciles de mantener, y que faciliten la gestión diaria.
2. Especificaciones de diseño para el valor, incluido evitar bigkey, elegir métodos de serialización y métodos de compresión eficientes, usar grupos compartidos de objetos enteros y selección de tipos de datos.

• ② Especificación 1: Especificación de nomenclatura clave: use el nombre comercial como prefijo y luego sepárelo con dos puntos, más el nombre de los datos comerciales específicos (de esta manera, podemos distinguir diferentes datos comerciales a través del prefijo clave, y hay no es necesario alternar entre bases de datos)
  La clave en sí es una cadena y la estructura de datos subyacente es SDS. La estructura SDS contendrá información de metadatos, como la longitud de la cadena y el tamaño del espacio asignado. A partir de la versión Redis 3.2, cuando aumenta la longitud de la cadena de claves, los metadatos en SDS también ocuparán más espacio de memoria.

• ③.Especificación 2: Evite el uso de bigkey.
  Redis usa un solo hilo para leer y escribir datos. Las operaciones de lectura y escritura de bigkey bloquearán el hilo y reducirán la eficiencia de procesamiento de Redis. Al aplicar Redis, un punto muy importante con respecto a las especificaciones de valor del diseño es evitar bigkey

1. El tamaño del valor del par clave-valor en sí es grande, por ejemplo, el valor es 1 MB de datos de tipo Cadena. Para evitar bigkey de tipo String, en la capa empresarial, debemos intentar controlar el tamaño de los datos de tipo String a menos de 10 KB.
2. El valor del par clave-valor es un tipo de colección y la cantidad de elementos de la colección es muy grande, como los datos del tipo de colección Hash que contienen 1 millón de elementos. Para evitar la gran clave del tipo de colección, mi sugerencia de especificación de diseño es intentar controlar el número de elementos del tipo de colección a menos de 10,000.

• 4. Especificación 3: Utilice métodos de serialización y métodos de compresión eficientes

1. Para ahorrar memoria, además de utilizar estructuras de datos compactas, también podemos seguir dos especificaciones de uso, a saber, utilizar métodos de serialización eficientes y métodos de compresión, que pueden reducir el tamaño del valor.
2. Los datos en formatos XML y JSON ocupan un espacio de memoria relativamente grande. Para evitar que los datos ocupen demasiado espacio en la memoria, recomiendo utilizar herramientas de compresión como snappy o gzip para comprimir los datos y luego escribirlos en Redis, ahorrando así espacio en la memoria.

• ⑤.Especificación 4: utilizar grupo compartido de objetos enteros

1. Si un par clave-valor contiene un número entero entre 0 y 9999, Redis no creará un objeto entero específicamente para este par clave-valor, pero reutilizará el objeto entero en el grupo compartido, incluso si hay una gran cantidad de valores clave. los pares guardan de 0 a 9999. Para números enteros en el rango de 9999, en la instancia de Redis, en realidad solo se guarda un objeto entero, lo que puede ahorrar espacio en la memoria.
2. Entonces, ¿cuándo no podemos usar el grupo compartido de objetos enteros? Hay dos situaciones principales
   : La primera situación es que si maxmemory está configurado en Redis y la política LRU allkeys-lru o volatile-lru está habilitada, entonces el grupo compartido de objetos enteros no se puede usar. Esto se debe a que la estrategia LRU necesita contar el tiempo de uso de cada par clave-valor. Si diferentes pares clave-valor comparten un objeto entero, la estrategia LRU no puede realizar estadísticas. El segundo caso es si los datos del tipo de colección utilizan codificación ziplist
   . Y los elementos de la colección son números enteros. En este momento, el grupo compartido no se puede utilizar. Debido a que ziplist utiliza una estructura de memoria compacta, es ineficiente determinar el uso compartido de objetos enteros.

sugerencias-redis

• ①. Separe los datos fríos y calientes, no coloque todos los datos en Redis
  . Aunque Redis admite la persistencia, todo el almacenamiento de datos de Redis está en la memoria, lo cual es costoso. Se recomienda almacenar solo datos activos de alta frecuencia en Redis según el negocio [QPS es mayor que 5000] Para datos fríos de baja frecuencia, puede utilizar métodos de almacenamiento basados ​​en disco como MySQL/ElasticSearch/MongoDB, que no no solo ahorra costos de memoria, sino que también reduce el volumen de datos y acelera las operaciones.Más rápido y más eficiente

• ②. Los diferentes datos comerciales deben almacenarse por separado.
  No coloque todos los datos comerciales irrelevantes en una instancia de Redis. Se recomienda que las nuevas empresas soliciten nuevas instancias separadas. Debido a que Redis es de un solo subproceso, el almacenamiento independiente reducirá el impacto de diferentes operaciones comerciales y mejorará la velocidad de respuesta de las solicitudes; también evita la expansión excesiva del volumen de datos de la memoria de una sola instancia y puede restaurar los servicios más rápido cuando ocurre una anomalía. En el uso real, el mayor cuello de botella de Redis es generalmente la CPU. Dado que es un trabajo de un solo subproceso, puede llenar fácilmente una CPU lógica. Puede utilizar un agente de Redis o una solución distribuida para mejorar el uso de la CPU de Redis.

• ③. Se debe establecer un período de tiempo de espera para la clave almacenada.
  Si la aplicación coloca a Redis como caché, se debe establecer un período de tiempo de espera para la clave almacenada. Porque si no se configuran, estas claves siempre ocuparán memoria y no se liberarán, lo que provocará un gran desperdicio. Además, a medida que pase el tiempo, el uso de memoria será cada vez mayor hasta que se alcance el límite de memoria del servidor. Además, la duración del tiempo de espera de la clave debe evaluarse exhaustivamente en función del negocio, ¡no cuanto más tiempo, mejor!

• ④. Para datos de texto grandes que deben almacenarse, deben comprimirse y almacenarse.
  Al escribir texto grande [+ más de 500 bytes] en Redis, deben comprimirse y almacenarse. Almacenar datos de texto grandes en Redis no solo ocupa mucha memoria, sino que también llena fácilmente la tarjeta de red cuando el tráfico es alto, lo que hace que todos los servicios en todo el servidor dejen de estar disponibles y desencadene un efecto de avalancha, lo que provoca que todos los sistemas queden paralizados.

• ⑤. Redis en línea prohíbe el uso de operaciones regulares de coincidencia de claves.
  Redis es un proceso de un solo subproceso. Cuando hay una gran cantidad de LLAVES en línea, la eficiencia de la operación es extremadamente baja [la complejidad del tiempo es O (N)]. Una vez que este comando Cuando se ejecuta, bloqueará seriamente otros comandos en línea. Las solicitudes normales y en situaciones de alto QPS provocarán directamente que el servicio Redis falle. Si tiene necesidades similares, utilice el comando de escaneo en su lugar.

• ⑥.Convención de nomenclatura

1. Aunque Redis admite múltiples bases de datos, el valor predeterminado es 32 y se pueden configurar más, pero excepto la biblioteca predeterminada No. 0, todas las demás requieren una solicitud adicional para usarse. Por lo tanto, sería más prudente utilizar el prefijo como espacio de nombres.
2. Además, cuando se usan prefijos como espacios de nombres para separar diferentes claves, es mejor usar la configuración global en el programa. Se debe evitar estrictamente la práctica de escribir prefijos directamente en el código, de esta manera la mantenibilidad es realmente pobre.
3. Por ejemplo: nombre del sistema: nombre comercial: datos comerciales: otros, pero tenga en cuenta que el nombre de la clave no debe ser demasiado largo. Trate de ser claro y fácil de entender. Debe medirlo usted mismo.

• ⑦. Deshabilite
  los clústeres centrales de cadenas grandes y deshabilite las claves grandes de cadenas de 1 MB (aunque redis admite cadenas de 512 MB). Si una clave de 1 MB se escribe repetidamente 10 veces por segundo, provocará que la E/S de la red se escriba en 10 MB.

• ⑧. Utilice razonablemente diferentes tipos de estructuras de datos según los escenarios comerciales.
  Actualmente, Redis admite muchos tipos de estructuras de bases de datos: cadena, hash, lista, conjunto, conjunto clasificado, mapa de bits, HyperLogLog e índice geoespacial, etc. Debe elegir el tipo apropiado según los escenarios comerciales. al escenario empresarial.
  Los más comunes incluyen: String se puede usar como KV ordinario, clase de conteo; Hash se puede usar como objetos como productos básicos, corredores, etc., que contienen información con más atributos; List se puede usar como cola de mensajes, lista de seguidores/seguidores, etc. .; Set se puede utilizar para recomendaciones; SortedSet se puede utilizar para clasificaciones, etc.

• ⑨. Tenga cuidado al utilizar estructuras de colección completamente operativas como Hash y Set.
  Cuando se utiliza la estructura HASH para almacenar atributos de objetos, al principio solo hay una docena limitada de campos. HGETALL se usa a menudo para obtener todos los miembros, lo cual también es muy eficiente. Sin embargo, a medida que el negocio se desarrolle, los campos se expandirán a cientos o incluso cientos, y el uso de HGETALL en este momento causará problemas como una fuerte caída en la eficiencia y el llenado frecuente de la tarjeta de red [complejidad de tiempo O (N)]. esta vez, se recomienda dividirlo en múltiples estructuras Hash según el negocio; o si la mayoría de las operaciones son para obtener todos los atributos, ¡puede serializar todos los atributos en un almacenamiento de tipo STRING! ¡Lo mismo ocurre cuando se utilizan SMEMBERS para operar el tipo de estructura SET!

• ⑩. Está prohibido utilizar el comando monitor en línea.
  Está prohibido utilizar el comando monitor en el entorno de producción. En condiciones de alta concurrencia, el comando monitor tendrá peligros ocultos de explosión de memoria y afectará el rendimiento de Redis.

• ⑩①.redis capacidad
  No se recomienda que el tamaño de memoria de una sola instancia sea demasiado grande, y se recomienda que esté entre 10 y 20 GB.
  Se recomienda que la cantidad de claves contenidas en una instancia de Redis se controle dentro de 1 kW. Si la cantidad de claves en una sola instancia es demasiado grande, es posible que las claves caducadas no se reciclen de manera oportuna.

• ⑩②. Confiabilidad.
  Es necesario monitorear regularmente la salud de Redis: use varias herramientas de monitoreo de salud de Redis. Si no es posible, puede devolver información de Redis regularmente. Intente usar enlaces largos del grupo de conexiones
  y reconexión automática para las conexiones de los clientes.