¡Acostúmbrate a escribir juntos! Este es el primer día de mi participación en el "Nuggets Daily New Plan · April Update Challenge"
【Descripción del problema】
- El servicio de interfaz de negocios en línea inmediatamente comenzó a expirar y alarmar, y la tasa de disponibilidad del puerto de llamada ascendente se redujo al 80 %.
【Nivel de accidente】
- P0
【proceso】
- 19:44 Recibida una alarma, la interfaz tp99 supera los 300ms (8ms en circunstancias normales)
- 19:50 Verifique el monitoreo de la máquina y descubra que algunas máquinas han caducado, y las máquinas problemáticas aleatoriamente no están reparadas;
- 19:55 Esta interfaz depende del caché, hay un interruptor de degradación, consulta db (confirma que el interruptor está apagado)
- 19:58 Verificando el monitoreo del clúster de caché, no se encontraron problemas de clientes de caché en general
- 20:03 Asistencia de operación y mantenimiento para ver el clúster para confirmar que no hay ningún problema con el servidor de caché
- 20:10 Escanea la copia en caché y encuentra que una sola clave grande supera los 5M y continúa solicitando
- 20:13 Elimina la llave grande y restaura el clúster
[Causa del error] ¡Problema de clave grande de caché!
Resumir:
Con el impacto continuo del alto tráfico concurrente, varios marcos distribuidos y cachés distribuidos se han convertido en las pilas de tecnología comunes de las principales empresas de Internet. Entre ellos, redis cache, como pila de tecnología de caché distribuida, responde a solicitudes de alta frecuencia concurrente y rápido. las respuestas se convierten en las mejores en el almacenamiento en caché.
En nuestras entrevistas habituales, a menudo nos preguntan cómo lidiar con la clave almacenada en caché. A continuación, recurrimos al conocimiento de la medicina tradicional china para analizar cómo encontrar la clave almacenada en caché. Si juzgamos la clave almacenada en caché, ¿cómo resolver la clave almacenada en caché? .
ver
En un servicio de interfaz, si el cliente donde se encuentra nuestro servicio solo está conectado al clúster de caché, ¿cómo podemos confirmar rápidamente si es un problema de clave de caché en función de los indicadores?
Primero, elimine el problema de hardware del clúster del servidor redis:
primero usamos los indicadores del clúster para determinar si hay una anomalía en la máquina del servidor de caché, lo que hace que se agote el tiempo de respuesta, observe los indicadores de la máquina del servidor redis, la CPU, la memoria , red, etc., y excluya el problema de hardware del servidor redis.
oler
A continuación, descubra el fenómeno de que se interrumpe el tiempo de espera de la conexión del cliente y por qué se interrumpen el servidor del cliente y la conexión del servicio Redis.
Apariencia 1: el tráfico entrante de fragmentos redis no es grande, pero el tráfico saliente es enorme
Aspecto 2: cada vez que el fragmento redis especificado supera el tiempo de espera correspondiente, el tráfico saliente es enorme, mientras que el tráfico saliente de otros fragmentos es normal
我们先要清楚一个知识点，就是缓存的数据路由，Redis Cluster采用虚拟哈希槽分区而非一致性hash算法，预先分配16384(2^14)个卡槽，所有的键根据哈希函数映射到 0 ~ 16383整数槽内，每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。
所以我们存入redis的每一条数据，在分片不变的情况下，始终存储在一个分片上。我们根据这个特点，结合监控集群的指标反应，可以快速定位是否是缓存大key。
正常情况下出流量各个分片出流量监控：
缓存大key导致的固定分片出流量大：
这种基本就可以确定是缓存大key的问题了，我们继续下一步，如何快速找到这些缓存大key，并且删掉
问
找到问题的缓存分片，针对缓存分片进行大key扫描，网上方法有很多，感兴趣的话可以自己搜索，在此只介绍集中比较热门的方式。建议公司运维同事提前搭好类似的基础服务工具。
1、redis-rdb-tools工具。redis实例上执行bgsave，然后对dump出来的rdb文件进行分析，找到其中的大KEY。 关于rdb工具的详细介绍请查看链接github.com/sripathikri… 基本命令：rdb -c memory dump.rdb (dump.rdb为Redis实例的rdb文件，可通过bgsave生成)
2、redis-cli --bigkeys命令。可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。
3、自定义的扫描脚本，以Python脚本居多，方法与redis-cli --bigkeys类似。
自此可以找出缓存的中的大key。执行 del 命令删除大key即可。
切
我们如何预防，才是重点。
1、redis本身定位就是一个内存缓存，而不是一个数据库，所以我们如果涉及到复杂的数据结构，建议设计之初就应该进行拆分。
2、在所有set缓存方法前，增加切面校验，设定阈值，校验存储的缓存key-value的大小，如果超过的话，阻止录入并且计入报警。
最后我们解释下，为什么缓存大key会导致服务端链接缓存超时链接中断的现象。
先了解一个概念，redis缓冲区一共有三个，客户端缓冲区、复制及压缓冲区、AOF缓冲区，大key问题导致客户端-服务端链接中断的原因就在于第一个：客户端缓冲区
Redis为每个客户端分配了输入缓冲区， 它的作用是将客户端发送的命令临时保存， 同时Redis从会输入缓冲区拉取命令并执行， 输入缓冲区为客户端发送命令到Redis 执行命令提供了缓冲功能， 如图所示。
Redis 为每个客户端设置的输出缓冲区也包括两部分：一部分，是一个大小为 16KB 的固定缓冲空间，用来暂存 OK 响应和出错信息；另一部分，是一个可以动态增加的缓冲空间，用来暂存大小可变的响应结果。造成输出缓冲区溢出的原因：
大key请求返回的结果
执行了Monitor命令
缓冲区设置大小不合理
限制输出缓冲区的配置
client-output-buffer-limit normal 0 0 0 普通客户端不做限制，请求是阻塞式的
client-output-buffer-limit pubsub 8mb 2mb 60 发布订阅式 总量8mb 60s内超过2mb就会自动关闭连接
避免溢出的方式显而易见:
避免bigkey
生产不使用Monitor操作
合理设置client-output-buffer-limit
复制代码