系统做Prime的活动，在18点开启。主要针对已登录用户。根据监控，该时间段大概有19万用户同时在线。
在准点开启时，突然用户侧报警群中出现有异常。开始紧急排查。
观察本身系统监控、日志正常，说明是从入口处到系统处有异常。
观察NG的日志，发现有大量的504。
504通常用来被用于反压统一标准错误码。说明有大量请求被反压，无法进入系统。
系统当前总流量，未见明显徒增。
瞬间流量打到了8万5，大概有3000多流量被504拦截。
使用的undertow的容器，观察工作线程池监控，发现活跃线程数只有11，远未达到上限。
未达到上限但是被反压，说明undertow参数设置的有问题。开始检查参数设置
request 的maximumConcurrentRequests，设置的300。queueSize也是设置的300。
说明系统当前处理的请求达到了上限300，请求进入queue，然后后续的请求就被反压了。
调整该参数大小，先暂时扩至600，并增加了实例规则、数量，抗过了后续的单接口瞬间12万流量冲击。
观察CPU情况 ，打到了1.25左右，4C的规格，一C大概26%的利用率。说明CPU还未达到上限，仍有提高空间。大量的请求，都是IO类，未涉及到计算类。
分析login/check接口，该接口延迟，导致系统异常。P95毛刺升到35ms。
该接口的业务逻辑简单，只经过2次redis，一次限频redis，一次业务redis(从redis获取用户信息)。
限流redis与业务redis进行了拆分。
业务redis的ops，峰值在4k左右，未达到上限，同时latency平滑。说明延迟不是业务redis造成。
同理限流redis
说明延迟，主要发生在系统内部，包括等待工作线程、redis连接池。
login/check接口的流量从何来？
经过与前端核实，是前端在本次活动开始时，用户如果要抢购，那会先经过一次login/check，导致段时间内有大量流量打过来。
其实用户本来已经是登录态，不需要经过login/check，属于前端乱用接口导致。
反思：
1. 压缩成本，导致实例规格从16C32G压缩至4C8G，未引起重视。
2、关键的参数未经过压测，调整规格后仍需进行压测。
3、需要评估系统各个接口容量。
4、业务方调用接口，需要问清楚应用场景，防止业务方卵用造成压力。
5、虽已对热点接口限流从redis转为本地，但仍有新接口出现突增的流量。需要能从日常请求中，找到前端新增调用的接口，提前转为本地限流。
