问题描述

部署在AKS中的应用，连接Redis高频率出现timeout问题

问题解答

查看Redis状态，没有任何异常，服务没有更新，Service Load， CPU， Memory， Connect等指标均正常。在排除Redis端问题后，转向了AKS中。

开始调查AKS的网络状态。最终发现每次Redis客户端出现超时问题时，几乎都对应了AKS NAT Gateway的更新事件，而Redis服务端没有任何异常。因此，超时问题很可能是由于NAT Gateway更新事件导致TCP连接被重置。

NAT更新原理: 在NAT Gateway的底层组件更新初期，被更新的内部实例将不会接受新的连接请求。在接下来的更新时间里，所有传入的数据包都将收到TCP RST（重置）消息作为响应。而后存量连接被清空，实例就会进入更新流程。此操作确保在更新过程中，客户端可以自动与其他未更新实例重新建立连接，从而尽量减少对业务的影响。

如何监控NAT更新: 可以通过NAT Gateway的Datapath Availability的指标来监控NAT网关是否发生了更新。在更新期间NAT Gateway的Datapath Availability会略微下降至98%及以下， 这可以作为判断维护状态的一个参考 :  Azure NAT 网关的指标和警报 - Azure NAT Gateway | Microsoft Learn  

面对如此情况，可作如下调整：

1. Redis设置较短的超时时间，这样可以更快地在客户端层面重新建立连接，同时，负面效果是提高了超时报错的几率。对于高操作频率的Redis，较短的超时时间依然是一个比较好的方案。
2. 可以将AKS 所在的Linux系统中的net.ipv4.tcp_retries2参数修改得更小，使TCP底层连接更快地重连。https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-best-practices-connection#tcp-settings-for-linux-hosted-client-applications
3. 可以尝试让Redis客户端建立更多连接数量，通过分散的出站连接，减少NAT Gateway实例更新对客户端连接的影响。