误用.Net Redis客户端CSRedisCore,自己挖坑自己填 - _小码甲 - 博客园

来源: 误用.Net Redis客户端CSRedisCore,自己挖坑自己填 – _小码甲 – 博客园

前导  #

上次Redis MQ分布式改造完成之后, 编排的容器稳定运行了一个多月,昨天突然收到ETL端同事通知,没有采集到解析日志了。

赶紧进服务器看了一下,用于数据接收的receiver容器挂掉了, 尝试docker container start [containerid],  几分钟后该容器再次崩溃。

 

Redis连接超限#

docker log [containerid]  查看容器日志; 重点:CSRedis.RedisException: ERR max number of clients reached

docker logs [containerid]

日志上显示连接Redis服务器的客户端数量超限,头脑快速思考,目前编排的某容器使用CSRedisCore 对于16个Redis DB实例化了16个客户端,但Redis服务器也不至于这么不经折腾吧。

赶紧进redis.io官网搜集相关资料

After the client is initialized, Redis checks if we are already at the limit of the number of clients that it is possible to handle simultaneously (this is configured using the maxclients configuration directive, see the next section of this document for further information).

In case it can’t accept the current client because the maximum number of clients was already accepted, Redis tries to send an error to the client in order to make it aware of this condition, and closes the connection immediately. The error message will be able to reach the client even if the connection is closed immediately by Redis because the new socket output buffer is usually big enough to contain the error, so the kernel will handle the transmission of the error.

大致意思是:Redis服务器maxclients配置了最大客户端连接数, 如果当前连接的客户端超限,Redis会回发一个错误消息给客户端,并迅速关闭客户端连接。

立刻登录Redis服务器查看默认配置,确认当前Redis服务器maxclients=10000(这是一个动态值,由maxclients和最大进程文件句柄决定),

# Set the max number of connected clients at the same time. By default
# this limit is set to 10000 clients, however if the Redis server is not
# able to configure the process file limit to allow for the specified limit
# the max number of allowed clients is set to the current file limit
# minus 32 (as Redis reserves a few file descriptors for internal uses).
#
# Once the limit is reached Redis will close all the new connections sending
# an error ‘max number of clients reached’.
# maxclients 10000

 左图表明:通过Redis-Cli 登录进服务器立即就被踢下线。

基本可认定redis客户端使用方式有问题。

 

CSRedisCore使用方式#

继续查看相关资料,可在redis服务器上利用redis-cli命令:info clients、client list仔细分析客户端连接。

info clients 命令显示现场确实有10000的连接数;

client list命令显示连接如下:

官方对client list命令输出字段的解释:

  • addr: The client address, that is, the client IP and the remote port number it used to connect with the Redis server.
  • fd: The client socket file descriptor number.
  • name: The client name as set by CLIENT SETNAME.
  • age: The number of seconds the connection existed for.
  • idle: The number of seconds the connection is idle.
  • flags: The kind of client (N means normal client, check the full list of flags).
  • omem: The amount of memory used by the client for the output buffer.
  • cmd: The last executed command.

根据以上解释,表明 Redis服务器收到很多ip=172.16.1.3(故障容器在网桥内的Ip 地址)的客户端连接,这些连接最后发出的是ping命令(这是一个测试命令)

故障容器使用的Redis客户端是CSRedisCore,该客户端只是单纯将 Msg 写入Redis list 数据结构,CSRedisCore上相关github issue给了我一些启发。

发现自己将CSRedisClient实例化代码写在 .netcore api Controller构造函数,这样每次请求构造Controller时都实例化一次Redis客户端,最终Redis客户端连接数达到最大允许连接值。

依赖注入三种模式: 单例(系统内单一实例,一次性注入);瞬态(每次请求产生实例并注入);自定义范围。

有关dotnet apicontroller 以瞬态模式 注入,请查阅链接

还有一个疑问? 为什么Redis服务器没有释放空闲的 客户端连接,如果空闲连接被释放了,即使我写了low代码也不至于如此吧?

查询官方:

By default recent versions of Redis don’t close the connection with the client if the client is idle for many seconds: the connection will remain open forever.

However if you don’t like this behavior, you can configure a timeout, so that if the client is idle for more than the specified number of seconds, the client connection will be closed.

You can configure this limit via redis.conf or simply using CONFIG SET timeout <value>.

大致意思是最近的Redis服务端版本 默认不会释放空闲的客户端连接:

# Close the connection after a client is idle for N seconds (0 to disable)
timeout 0

可通过修改Redis配置释放 空闲客户端连接。

我们最佳实践当然不是修改Redis idle timeout 配置,问题核心还是因为我实例化了多客户端,赶紧将CSRedisCore实例化代码移到startup.cs并注册为单例。

 

大胆求证#

info clients命令显示稳定在53个Redis连接。

client list命令显示:172.16.1.3(故障容器)建立了50个客户端连接,编排的另一个容器webapp建立了2个连接,redis-cli命令登录到服务器建立了1个连接。

client list命令显示连接

那么问题来了,修改之后,receiver容器为什么还稳定建立了50个redis连接?

进一步与CSRedisCore原作者沟通,确定CSRedisCore有预热机制,默认在连接池中预热了50个连接。

bingo,故障和困惑全部排查清楚。

 

总结#

经此一役,在使用CSRedisCore客户端时, 要深入理解

① Stackexchange.Redis 使用的多路复用连接机制(使用时很容易想到注册到单例),CSRedisCore开源库采用连接池机制,在高并发场景下强烈建议注册为单例, 否则在生产使用中可能会误用在瞬态请求中实例化,导致redis客户端几天之后被占满。

② CSRedisCore会默认建立连接池,预热50个连接, 开发者心里要有数。

额外的方法论: 尽量不要从某度找答案,要学会问问题,并尝试从官方、stackoverflow 、github社区寻求解答,你挖过的坑也许别人早就挖过并踏平过。

 

——————————update  多说两句———————————————

很多博友说问题在于我没有细看CSRedisCore官方readme(readme推荐使用单例),使用方式上我确实没有做成单例:

③ 一般连接池都会有空闲释放回收机制 (CSRedisCore也是连接池机制),所以当时并没有把 单例放在心上

④ 本次重要知识点:Redis默认并不会释放空闲客户端连接(但是又设置了最大连接数),这也直接促成了本次容器崩溃事故。

嗯,坑是自己挖的。

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏