问题描述

Azure Redis是高可用架构，由主节点，从节点 两个节点共同组成。

应用客户端连接的Redis服务器的域名，经过DNS解析为上图中Load Balancer的IP，然后连接转发到主节点。发生故障转移(Failover)是LB后的两个Primary和Replica 节点进行了切换，这个期间没有DNS变动。

对于以上情况，有如下疑问：

1：Load Balancer 没有保持和客户端的连接，需要客户端重建连接到新主节点。那为什么Redis连接数指标上一直显示有大量的链接呢？

2：这些大量的连接，是如何产生的呢？ 按照应用中的配置计算，达不到上万连接的数量级。如何解释这种情况呢？

3：对于Redis的Server Load指标，每秒创建连接数的并发值，是否有建议呢？

问题解答

1：Load Balancer 没有保持和客户端的连接，需要客户端重建连接到新主节点。那为什么Redis连接数指标上一直显示有大量的链接呢？

【答】：任何时候发生故障转移（主节点离线）或副本节点离线时，其中一个节点会暂时下线。在下线之前，该节点会关闭所有终止于它的客户端连接。预计客户端库会自动重新连接以恢复关闭的连接，Load Balancer 会将该替换连接路由到另一个仍在线的节点。

如果客户端应用程序在切换到第二个缓存时没有正确关闭与原始缓存的连接。如果这些连接确实被放弃且不再接收任何流量或保持活动的 ping，那么服务器将在 10 分钟空闲超时后关闭它们。这些没有正常关闭的连接会导致Redis连接数指标上显示大量连接数。

2：这些大量的连接，是如何产生的呢？ 按照应用中的配置计算，达不到上万连接的数量级。如何解释这种情况呢？

【答】：缓存内的节点（主节点和副本）发出连接指标，报告的总连接数是每个节点上终止的客户端连接的总和（转发的连接不会被重复计算）。如果这些指标显示的数量高于预期，那么客户端应用程序内部存在连接泄漏，或者 Redis 客户端库内部存在连接泄漏。

3：对于Redis的Server Load指标，每秒创建连接数的并发值，是否有建议呢？

【答】：为了避免将缓存推到 100% 服务器负载，建议将连接创建速率保持在每秒 30 个以下。

当然也可以以更高的速率创建连接（尤其是在更高定价层的Redis上），但这可能会导致Redis Server Load瞬间达到 100% ，并且导致对其它正常的Redis请求的响应变慢，甚至出现Timeout异常。在这种情况下，大部分Redis客户端能正常处理，但是Redisson 无法处理，很可能引发连接风暴。

参考资料

Azure Redis 高可用性和灾难恢复  : https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-high-availability#standard-replication-for-high-availability

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!