7月2日晚上10点之后，负责的服务（redis.clients.jedis.exceptions.JedisConnectionException）中发生了大量Redis连接超时异常，因为数据库查询在Redis中缓存了2分钟，并且没有降级已经完成。
采取措施后，并不能做限流处理，并且随着中午高峰时间的流量猛增，并且QPS从10点开始达到2000，在11点时达到了13000 QPS的峰值。
幸运的是，redis超时导致的某些查询失败不会导致整个主链接过程不可用，因此下一步就是如何快速查找和解决问题。
1.首先与负责redis的同学核对，首先消除redis本身的问题。
2.如果在独立维度上可以看到服务自检的异常分布，请切换到独立维度以检查异常是否均匀分布。
如果分布不均匀，则只有少量主机非常高，您基本上可以找到发生问题的计算机的Redis负载。
根据传统经验，检查redis集群的节点负载是否过高，例如80％。
如果超过一个或少量节点，则表明存在“热键”。
问题。
如果大多数节点超过它，则意味着存在“降低总体压力”的问题。
检查监视慢请求。
如果慢速请求的时间与问题发生的时间匹配，则可能存在“大键”。
问题。
客户端的几个常见原因是：CPU进程，GC，网络容器，主机，CPU，观察机器或容器的CPU：CPU（100％）是否接近或超过80％CPU电流限制。
是否有密集电流限制或长期电流限制。
如果存在这些现象，则应该是“计算资源不足”的问题。
处理GC频繁使用GC或GC消耗时间太长将导致无法安排线程及时读取redis响应。
通常是每分钟的总GC持续时间/ 60s /每分钟的GC数量。
如果达到ms级别，则对redis的读写延迟的影响将很明显。
然后，比较与以前的正常时间相比是否有明显增加。
通常可以通过监视TCP重传速率来测量网络质量。
比率越低越好。
如果TCP重传率保持在0.02％以上（基于您的实际情况），或者其突然增加，则可以确定这是否是“网络问题”。
我的问题在这里，我实际上发现该容器的TCP重传率非常高，有的甚至达到了0.6％。
向容器咨询的同事建议重新启动容器，并在重新启动后立即解决问题。
继续谈论疑难解答的想法。
容器主机监视容器主机的CPU状况。
在某些情况下，该计算机是虚拟机，并且CPU的监视指示器可能不准确，尤其是在io密集型情况下。
可以通过OPS提供的其他方式查询。
由于机密性问题，无法放置该问题的屏幕截图，但这实际上是一个警钟。
关键链路中必须确保保险丝电流限制和降级措施。
重要的事情说了三遍，需要X3。
！而且原始的历史代码本身也有一些问题。
一年中的大部分时间都不会共享缓存的数据。
根本不需要Redis缓存。
内存级别的缓存就足够了，或者内存缓存+ redis也用作级别缓存一个更合理的计划。
在正常开发中，我们必须充分考虑数据的及时性，以进行相应的设计。
