早晨刚想出门，收到一个告警短信，物联网登录分配服务器正常节点异常。
一猜就是扛不住压力。
压力来自大量物联网设备以及 APP 在登录。
为什么压力大呢？
可能有地方有问题。
紧急处理，打开登录限流服务（Jenkins 任务）。
过了十分钟，恢复差不多。
但是，又出现了问题。
好家伙，开启降级服务，关闭物联网设备自动写上报数据到 redis 集群。
然后，就慢慢恢复正常了。

吃过早饭，骑车去公司。

坐到办公室，继续排查。
这个时候，其他同事已经陆续到了。
查看 redis 集群监控图，注意到一个 keys 指令几十毫秒。
记得之前有一位新来的研发工程师说 keys 会导致锁库，导致 select update 等类似 mysql 的指令无法正常工作。
研发同事去排查keys 指令。
可是这个与我们遇到的问题时间点上无法吻合。keys 指令是整点定时任务，可是问题出现在7:11 分多一点点。

架构师抛出来一张 redis 一个实例 cpu100%的图片。
这个可能是直接导致物联网长连接服务器异常的原因。

开始针对该redis 实例的问题进行排查。
redis 集群从三主三从升级到了八主八从，也消灭了一些大 key。
异常 redis 实例还挂掉了，导致了主从切换。
先把主从节点切换回来。
查看数据，对比不同实例，发现该异常节点 cpu 使用率 3 个月以来持续攀高，就在已经关停实现降级服务的情况下，依旧有将近 60 的使用率，而其他redis 节点大概只有 10%~30%的使用率。
多次比较后，发现了一个 keys 指令，对应的一个 key 大概是热key。
最终导致该节点每秒节点处理时长大概有 500ms 左右，而其他节点大概只有几十 ms。

定位了热key，跟研发同事一说，等他们修复了。

中午好好的吃了一些饭，少吃米，多吃菜。

本来以为下午可以看看书，整理整理文档，谁知一个运维代为服务客户发来一个视频，说是充值失败。
我寻思着，这充值是代码问题，为啥失败呢？且这个客户不知道为啥，只有一个服务器，没有文档，也不知道架构。
早先因为 tomcat 直接暴露了 8080 端口到公网，且是 两三年前部署的服务，被黑客攻击并进行了挖矿。
后来，加入了 waf 以及关闭了 8080 直接对外，更新了 https 证书，已经稳定运行了有半个多月。
看到客户在群里发消息，我只是在思考，没有先回答。

回到工位，开始搜索 pfx pem 等支付通信所用到的证书。
后来搜索到了一个 tengxun 支付的证书，但是没有与程序结合的线索。
干脆直接从日志中找找，搜索关键字 pay 还真找到了一些。
有通信参数，有接口地址。通过域名锁定了 tomcat 程序位置。
日志有 1GB，压缩下载到本地。
使用 ai 进行分割文件，每个 20MB。
通过 ide 工具从尾部向上找，找了几个找到了 pay 相关的具体日志。
通过 ai 分析，发现是 xstream 模块版本不支持反序列化（之前升级了有漏洞版本）。
这下心里大概有数了。

这个时候，用户也把今年充值的记录拿出来了，一个是 6 月份一个是 9 月份。
看来充值频率不是很高。
跟用户解释，可能是之前再做安全修复的时候（比照着阿里云安全中心给的提示），升级了包括 shiro fastjson xstream 在内的模块。
升级后，漏洞是补上了一些，但是由于没有源代码导致兼容性没有充分验证。

替换后，打开 tail 查看 catalina.out日志并过滤 pay。
过了好一会儿，看到终端提示有新数据，发现已经返回正常了。

长舒一口气，这一天。