Análisis del problema y la solución del sesgo de datos del clúster de Redis

Descripción general

En el desarrollo de servicios del sistema del lado del servidor, el almacenamiento en caché es una tecnología de uso común, que puede mejorar la eficiencia de procesamiento de solicitudes del sistema, y redis es líder en la pila de tecnología de almacenamiento en caché, ampliamente utilizada en varios sistemas de servicios. En los servicios de Internet a gran escala, hay solicitudes masivas para procesar y almacenar datos en caché todos los días. En estos sistemas a gran escala, es difícil cumplir con las solicitudes concurrentes ultra altas del sistema y los requisitos de caché de datos masivos con un solo -instancia redis. Para el uso de redis en servicios de Internet a gran escala, a menudo se adopta una arquitectura de clúster y la escala de instancias de redis se expande horizontalmente para mejorar la eficiencia de procesamiento y la capacidad de almacenamiento de datos del sistema de caché para solicitudes de datos a un costo menor.

Aunque la arquitectura de clúster de redis tiene muchas ventajas, las cosas suelen tener dos caras: después de resolver los problemas en algunos escenarios, causarán problemas en otros escenarios. Por supuesto, el modo de clúster de redis también se ajusta a esta regla. En el modo de clúster de redis, aumentará la complejidad de la operación y el mantenimiento, y limitará el uso de ciertos comandos en redis (consulta de rango, uso de operaciones de transacción, etc.) Además de estos problemas comunes, el problema del sesgo de datos es un problema en el modo clúster de redis Un problema relativamente oculto que solo aparece en algunos escenarios especiales, pero el impacto de este problema es enorme.

Ejemplo

Para el servicio de lotería del Festival de Primavera de 2019, el qps máximo de evaluación comercial es de 2w, que se transforma en un clúster redis con 10w qps y 5GB de almacenamiento de memoria, e implementa 5 fragmentos de clústeres redis de 1GB+2W qps (incluida la capacidad reservada). Como resultado, cuando comenzó la actividad, se descubrió que había una "tecla de acceso rápido" en el servicio y la solicitud estaba severamente sesgada. a estar sobrecargado y todo el servicio de lotería a la avalancha.

¿Qué es el sesgo de datos?

En el modo de clúster de redis, los datos se distribuirán a diferentes instancias de acuerdo con ciertas reglas de distribución. Si debido a la particularidad de los datos comerciales, de acuerdo con las reglas de distribución especificadas, la distribución de datos en diferentes instancias puede ser desigual, como en los siguientes escenarios: algunas instancias de segmento tienen una gran cantidad de distribución de datos, algunas instancias tienen menos distribución de datos; Los datos calientes se guardan y el volumen de acceso a datos es relativamente grande, y los datos almacenados en algunas instancias son relativamente "fríos", casi sin volumen de acceso. Las instancias que almacenan una gran cantidad de datos o las instancias que almacenan datos calientes tendrán una mayor utilización de recursos y una mayor presión de carga, lo que resultará en respuestas más lentas a las solicitudes de datos. En este punto, se produce el sesgo de datos.

¿Qué tipo de sesgo de datos?

Los problemas de inclinación del clúster distribuido de Redis se dividen principalmente en dos categorías:

1. La capacidad de almacenamiento de datos está inclinada y el almacenamiento de datos siempre recae en una pequeña cantidad de nodos en el clúster;

2. La solicitud de qps está sesgada y el qps siempre se reduce a unos pocos nodos.

El impacto del sesgo de clúster de redis

El problema del sesgo tiene un mayor impacto en la memoria pura y los servicios de subproceso único como redis, y tiene los siguientes puntos débiles:

La concentración de qps en unos pocos nodos redis hará que algunos nodos se sobrecarguen, lo que arrastrará todo el servicio.Al mismo tiempo, la capacidad del clúster para procesar qps no es escalable;
La capacidad de datos está inclinada, lo que resulta en una explosión de memoria de una pequeña cantidad de nodos, OOM Killer y la capacidad de almacenamiento del clúster no son escalables;
La gestión de operación y mantenimiento se vuelve complicada, y es inconveniente unificar valores como monitoreo y alarmas de uso de memoria, QPS, número de conexiones y redis cpu ocupado;
Debido a que otros recursos de nodo en el clúster no se pueden utilizar por completo, la tasa de recursos del contenedor/servidor redis es baja;
Aumente la dificultad de la gestión automática de la configuración; intente unificar la configuración de parámetros de los nodos de un solo clúster;

Después de analizar el impacto, veamos las causas comunes del "sesgo" grave de los clústeres de Redis en el entorno de producción.

Causas comunes del sesgo de clúster de Redis

Generalmente, durante el diseño del sistema, el diseño del espacio de claves no es razonable:

Cuando se diseña el sistema, el diseño del espacio de claves redis (espacio de claves) no es razonable y aparecen "teclas de acceso rápido", lo que conduce a la sobrecarga de qps del nodo donde se encuentran dichas claves y al sesgo de qps del clúster;
Hay claves de colección grandes (hash, set, list, etc.) en el sistema, lo que conduce a la sobrecarga de la capacidad y QPS del nodo donde se encuentra la clave grande, y la inclinación de QPS y capacidad del clúster;
El DBA planifica incorrectamente el clúster o expande la capacidad, lo que resulta en una distribución desigual de la cantidad de ranuras de datos (slots), lo que genera una capacidad sesgada y solicita qps;
El sistema utiliza una gran cantidad de etiquetas hash de claves, lo que puede dar lugar a una gran cantidad de claves en algunas ranuras de datos y al sesgo de capacidad y qps del clúster;
El ingeniero ejecuta comandos como monitor, lo que hace que aumente el búfer de salida del cliente del nodo actual, se expande used_memory_rss, lo que resulta en un aumento en la capacidad de memoria del nodo y una inclinación de la capacidad;

A continuación, cuando la capacidad de la memoria, la cantidad de claves o el volumen de solicitudes de QPS del clúster están muy sesgados, ¿debemos solucionar el problema de posicionamiento?

Cómo solucionar problemas de sesgo de clúster de Redis

Verifique la clave del punto de acceso del nodo y determine los comandos principales.

Cuando el clúster qps está inclinado debido a las teclas de acceso rápido, es necesario ubicar rápidamente las teclas de acceso rápido y los comandos superiores. Puedes usar la herramienta de código abierto redis-faina, o es mejor tener una plataforma de análisis redis en tiempo real.

El siguiente es un análisis utilizando la herramienta redis-faina. Se puede ver que la relación QPS de las dos teclas de prefijo es básicamente del 50% cada una, y la tecla de acceso rápido es obvia; la excepción del comando auth (comandos superiores) también puede ser visto.

Overall Stats
========================================
Lines Processed         100000
Commands/Sec            7276.82

Top Prefixes
========================================
ar_xxx         49849   (49.85%)

Top Keys
========================================
c8a87fxxxxx        49943   (49.94%)
a_r:xxxx           49849   (49.85%)

Top Commands
========================================
GET             49964   (49.96%)
AUTH            49943   (49.94%)
SELECT          88      (0.09%)

Si el sistema usa claves de colección más grandes

El uso de una clave grande en el sistema hará que la capacidad del nodo del clúster o qps se sesgue. Por ejemplo, una clave hash con un campo de 5kw ocupa casi 10 GB de memoria. La capacidad de memoria o qps del nodo donde se encuentra la clave en la ranura es probable que esté sesgada.

Este tipo de clave de colección opera varios campos a la vez y es difícil encontrar el tamaño de la clave desde el proxy o SDK.

Puede usar redis-cli --bigkeys para analizar las claves grandes que existen en el nodo. Si necesita un análisis completo, puede usar redis-rdb-tools (https://github.com/sripathikrishnan/redis-rdb-tools) para analizar la cantidad total del archivo RDB del nodo y obtener la cantidad de memoria. bytes ocupados por la clave grande a través de la columna de resultado size_in_bytes.

Ejemplo usando redis-cli para análisis de muestreo:

redis-cli  --bigkeys -p 7000                                 

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest string found so far 'key:000000019996' with 1024 bytes
[48.57%] Biggest list   found so far 'mylist' with 534196 items
-------- summary -------
Sampled 8265 keys in the keyspace!
Total key length in bytes is 132234 (avg len 16.00)

Biggest string found 'key:000000019996' has 1024 bytes
Biggest   list found 'mylist' has 534196 items

8264 strings with 8460296 bytes (99.99% of keys, avg size 1023.75)
1 lists with 534196 items (00.01% of keys, avg size 534196.00)

Compruebe si la distribución de ranuras de datos de cada fragmento en el clúster es uniforme

A continuación, se toma el clúster Redis Cluster como ejemplo para confirmar la cantidad de ranuras de datos (ranuras) y claves de las que cada nodo es responsable en el clúster. Algunos ejemplos de las siguientes demostraciones no son ligeramente "sesgadas" pero no son serias, y se puede considerar una reposición.

redis-trib.rb info redis_ip:port
nodeip:port (5e59101a...) -> 44357924 keys | 617 slots | 1 slaves.
nodeip:port (72f686aa...) -> 52257829 keys | 726 slots | 1 slaves.
nodeip:port (d1e4ac02...) -> 45137046 keys | 627 slots | 1 slaves.
---------------------省略------------------------
nodeip:port (f87076c1...) -> 44433892 keys | 617 slots | 1 slaves.
nodeip:port (a7801b06...) -> 44418216 keys | 619 slots | 1 slaves.
nodeip:port (400bbd47...) -> 45318509 keys | 614 slots | 1 slaves.
nodeip:port (c90a36c9...) -> 44417794 keys | 617 slots | 1 slaves.
[OK] 1186817927 keys in 25 masters.
72437.62 keys per slot on average.

¿Utiliza el sistema etiquetas hash de claves de forma extensiva?

En un clúster de redis, algunas empresas usan etiquetas hash para asignar ciertos tipos de claves al mismo fragmento para lograr operaciones de múltiples claves, lo que puede generar datos y qps desiguales. Puede usar el escaneo para escanear si el espacio de claves usa etiquetas hash, o usar las herramientas monitor, vc-redis-sniffer para analizar los nodos sesgados y verificar si Dali contiene claves con etiquetas hash.

¿La capacidad de la memoria está sesgada debido a un búfer de salida del cliente anormal?

Confirme si hay un uso anómalo del búfer de salida en el cliente, lo que provoca problemas de memoria excesivos; por ejemplo, cuando se ejecuta la sincronización completa del monitor, el comando de teclas o el esclavo, el búfer de entrada del cliente es demasiado grande.

En este caso, la memoria básica de la instancia de redis crecerá rápidamente y pronto retrocederá. Supervisando el uso del búfer de salida del cliente; consulte el siguiente ejemplo para el análisis:

# 通过监控client_longest_output_list输出列表的长度，是否有client使用大量的输出缓冲区.
redis-cli  -p 7000 info clients
# Clients
connected_clients:52
client_longest_output_list:9179
client_biggest_input_buf:0
blocked_clients:0

# 查看输出缓冲区列表长度不为0的client。 可见monitor占用输出缓冲区370MB
redis-cli  -p 7000 client list | grep -v "oll=0"
id=1840 addr=xx64598  age=75 idle=0 flags=O obl=0 oll=15234 omem=374930608 cmd=monitor

Cómo evitar eficazmente el problema de sesgo del clúster de Redis

Cuando el sistema diseña el patrón de consulta y el espacio de claves del clúster de Redis, se deben evitar las teclas de acceso rápido.Si hay una lógica de teclas de acceso rápido, intente dispersar diferentes nodos o agregue un caché local del programa;
Al diseñar el espacio de claves del clúster redis en el sistema, debe evitar el uso de claves grandes y dividir el diseño de la clave; además del problema de la inclinación, las claves grandes tienen un grave impacto en la estabilidad del clúster;
Implementación de clústeres de Redis y procesamiento de expansión y contracción para garantizar la distribución uniforme de las ranuras de datos;
Desde la perspectiva del diseño del sistema, se deben evitar las etiquetas hash de claves;
En la operación y el mantenimiento diarios del sistema, debe evitar el uso directo de comandos como teclas y monitor, lo que hará que se acumule el búfer de salida; se recomienda cambiar el nombre de dichos comandos;
Configure el búfer de salida del cliente normal en total, se recomienda configurar 10 MB y el límite esclavo es de 1 GB, y ajústelo temporalmente según sea necesario (advertencia: confirme y ajuste con la empresa antes de modificar para evitar errores comerciales)

En los escenarios comerciales de producción reales, es difícil que los clústeres a gran escala logren un equilibrio completo de los clústeres, pero trate de asegurarse de que no ocurran problemas serios de sesgo.