Adquira o hábito de escrever juntos! Este é o primeiro dia da minha participação no "Nuggets Daily New Plan · April Update Challenge"
【Descrição do Problema】
- O serviço de interface de negócios on-line imediatamente começou a atingir o tempo limite e o alarme, e a taxa de disponibilidade da porta do chamador upstream caiu para 80%.
【Nível de Acidente】
- P0
【processo】
- 19:44 Recebido um alarme, a interface tp99 excede 300ms (8ms em circunstâncias normais)
- 19:50 Verifique o monitoramento da máquina e descubra que algumas máquinas atingiram o tempo limite e as máquinas com problemas não foram corrigidas aleatoriamente;
- 19:55 Esta interface depende do cache, existe um switch de downgrade, consulta db (confirme se o switch está desligado)
- 19:58 Verificando o monitoramento do cluster de cache, nenhum problema de cliente de cache foi encontrado em geral
- 20:03 Assistência de operação e manutenção para visualizar o cluster para confirmar que não há problema com o servidor de cache
- 20:10 Digitalize a cópia em cache e descubra que uma única chave grande excede 5M e continua a solicitar
- 20:13 Exclua a chave grande e restaure o cluster
[Causa da falha] Cache grande problema chave!
Resumir:
Com o impacto contínuo do alto tráfego simultâneo, várias estruturas distribuídas e caches distribuídos tornaram-se as pilhas de tecnologia comuns das principais empresas de Internet. Entre elas, o cache redis, como uma pilha de tecnologia de cache distribuída, está respondendo a solicitações de alta frequência simultânea as respostas se tornam as melhores em cache.
Em nossas entrevistas habituais, muitas vezes nos perguntam como lidar com a chave em cache. Em seguida, nos baseamos no conhecimento da medicina tradicional chinesa para analisar como encontrar a chave em cache. Se julgarmos a chave em cache, como resolver a chave em cache .
Vejo
Em um serviço de interface, se o cliente onde nosso serviço está localizado está conectado apenas ao cluster de cache, como podemos confirmar rapidamente se é um problema de chave de cache com base nos indicadores?
Primeiro, elimine o problema de hardware do cluster do servidor redis:
primeiro usamos os indicadores do cluster para determinar se há uma anormalidade na máquina do servidor de cache, o que faz com que a resposta expire, observe os indicadores da máquina do servidor redis, cpu, memória , rede, etc., e exclua o problema de hardware do servidor redis.
cheiro
Em seguida, descubra o fenômeno em que o tempo limite de conexão do cliente é interrompido e por que o servidor do cliente e a conexão do serviço redis são interrompidos.
Aparência 1: O tráfego de entrada de fragmentos redis não é grande, mas o tráfego de saída é enorme
Aparência 2: Cada vez que o fragmento de redis especificado atinge o tempo limite, o tráfego de saída é enorme; enquanto o tráfego de saída de outros fragmentos é 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
复制代码