昨晚，我们的门户雪崩已有一段时间了，这种现象是：
1.有多种微服务：编写HTTP响应时，连接已关闭：
2.同时，有一些尚未阅读的异常，并且连接已关闭：
3.前端有恒定的警报，504网关超时
4.网关过程继续重新启动并重新启动
5.重新启动的网关过程后，请求的数量立即飙升。每个实例峰值为2000 QP，每个实例的时间为500 QP，并且由于扩展而可以将每个实例保持在1000 QPS之内，然后健康检查接口非常好。不长时间响应，导致不断重新启动
其中，门户的问题应不断重新启动1和2的问题，出于某些原因，优雅的关闭故障导致强制性关闭，强迫关闭导致导致被迫断开连接的连接，并且有一个例外。1和2相关。
我们的网关基于弹簧云网关实现，并具有自动扩展CPU负载能力的机制。奇怪的是，当请求数量增加时，CPU利用率并没有增加很多，这将维持在60％的位置。。由于CPU负载未达到扩展的边界，因此它没有自动扩展。为了快速解决问题，我们手动扩展了几个网关实例，控制了1000范围内门户网关的负载，并暂时解决了问题。
为了完全解决此问题，我们使用JFR分析。首先根据已知的线索进行分析：
通常，健康检查界面的原因有两个：
我们可以首先看到JFR中的正时堆栈，以查看健康检查上是否存在HTTP线程。在问题后检查线程堆栈后，请重点关注4个HTTP线程。结果，这4个线程的堆栈基本上是相同的。他们正在执行redis命令：
发现HTTP线程不会粘在健康检查中，其他线程没有与健康检查有关的任何堆栈（在异步环境中，健康检查也异同步，其中一些可能会移交给其他线程）因此，应在执行之前取消健康检查请求。
那为什么这是呢？同时，我还发现这里的重新键盘是Spring-data-redis的同步redis api。当我突然记得我在这里写的代码时，因为我只是验证了键是否存在并修改了钥匙的到期时间，懒惰没有使用异步API。这是由使用API阻止HTTP线程引起的这种雪崩吗？
让我们验证以下猜想：我们项目中的重新操作是通过弹簧data-redis +生菜连接池来启用并添加有关生菜命令的JFR监视。监视方法不戳pke?我添加了一点调味品。截至目前，我的拉请请求已合并，此功能将在6.2.x版本中发布。LET对REDIS命令进行收集以在问题时间附近收集，如下图所示：
（因为它是10秒），每秒执行redis命令引起的阻塞时间：
这只是中位计算的阻塞时间。从图上的分布来看，实际上可以看出，实际值应该大于此。这可能是阻止REDIS同步接口每秒超过1秒的时间。请求没有减少，这导致请求越来越多，最后是雪崩。
而且由于它是一个封锁接口，所以线程是通过等待IO消耗的，因此CPU不可用，因此没有自动扩展。在业务的高峰期，由于有一个集合预expansion，Gateway实例确实可以没有达到问题的压力，因此没有问题。
让我们重写原始代码，并使用同步Spring-data-redis API的原始代码（实际上，Spring-Cloud-Gateway的滤波器接口的核心方法）：） :) :)：:)：:)：
更改使用异步：
这里有一些注意点：
修改后，测量了下部网关，并且单个实例2W QPS请求没有此问题。
微信搜索“我的编程Meow”会注意公共帐户。每天刷一刷刷子，以轻松改善技术并获得各种优惠