.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

Java中的SPI扩展机制(有demo)

前言:前两篇文章.net core+Redis+IIS+nginx实现Session共享中,介绍了使用Microsoft.Extensions.Caching.Redis实现Session共享的方法,但是高并发时会有连接Redis出现Timeout的问题,这篇文章将介绍该问题的解决方案。

1、环境及工具准备

操作系统:windows10

数据库:Redis

压力测试工具:JMeter(传送门

2、背景介绍

项目迁移到.net core并上线以后,运行没多久接口就频繁罢工,容器没有挂,redis、mogodb、sql server全都正常,容器重启后可以正常一下,但是没过多久就又罢工了,最后只有通过docker logs命令挨个去寻找容器日志中记录的错误信息,结果发现了StackExchange.Redis.RedisTimeoutException: Timeout performing EVAL。这里说明下是.net core2.2版本,不知道3.1版本还会不会有这个问题。

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

3、问题重现

打开JMeter压力测试工具 ,添加一个http请求

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

使用上篇文章发布在docker的地址和请求参数

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

设置线程数为500,循环次数为3,并运行,从汇总报告中可以看出,错误率高达50%以上

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 使用docker logs查看容器日志,发现了同线上一样的Redis连接超时错误,且Redis数据中缓存的数量只有668(理论上应该是500*3=1500)

 .Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

4、问题分析过程

(1)找到Redis组件注入的地方

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 (2)查看AddDistributedRedisCache源码,发现注入的是一个单例的IDistributedCache对象:

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 然后就发现RedisCache对象是用ConnectionMultiplexer管理Redis连接的

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

这里针对ConnectionMultiplexer对象做了线程安全

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

(3)进一步查看源码,也没有发现连接池的使用,而且从官网上的介绍来看,ConnectionMultiplexer中也没有连接池的概念,RedisCache对象中用于访问Redis数据库的私有属性_cache,并不是从连接池中获取对象,这样一来,在并发量较大的时候,会出现连接等待时间过长从而导致超时的问题,所以网上查看的类似将最小线程数设置大一些的解决方案并不可行;至于将TimeOut设置大一些,不仅不解决根本问题,还有悖于使用Redis的初衷。

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 .Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

5、解决方案

从第4步的分析来看,Microsoft.Extensions.Caching.Redis本身就不适合用于上篇文章介绍的Session共享方案,因为官网给出的注入对象,没有用连接池管理ConnectionMultiplexer,而ConnectionMultiplexer本身也没有池的概念。这里出两种解决方案:

(1)使用Sql Server替代Redis保存Session,这是我的一位同事找到的解决方案,并成功线上救火,这种方案代码实现简单,其它地方不需要改变。

嗨!请查收这道有趣的面试题

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 

 (2)使用CSRedis组件,替代Microsoft.Extensions.Caching.Redis,具体实现方式如下:

安装nuget包

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 

对照AddDistributedRedisCache,自定义AddDistributedCsRedisCache静态方法

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

public static class CsRedisTest
    {
        public static IServiceCollection AddDistributedCsRedisCache(this IServiceCollection services, CSRedis.CSRedisClient cSRedisClient)
        {
            if (services == null)
            {
                throw new ArgumentNullException("services");
            }

            if (cSRedisClient == null)
            {
                throw new ArgumentNullException("cSRedisClient");
            }
            //if (setupAction == null)
            //{
            //    throw new ArgumentNullException("setupAction");
            //}
            services.AddOptions();
            //services.Configure(setupAction);            
            services.Add(ServiceDescriptor.Singleton<IDistributedCache, CsRedisCacheTest>(factory => {
                return new CsRedisCacheTest(cSRedisClient);
            }));
            return services;
        }
    }

View Code

对照RedisCache类,自定义CsRedisCacheTest类,继承IDistributedCache接口,这里参考的是https://github.com/2881099/Microsoft.Extensions.Caching.CSRedis

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

修改Startup.cs的注册方式如下:

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

这里的defaultdatabase貌似只能设置为0,设置为其它值会报错,这点不如Microsoft.Extensions.Caching.Redis。

测试结果如下:

连接串poolSize为50,线程数500,循环次数3,测试通过(即Redis数据库成功缓存1500条数据,汇总报告中错误率为0)

连接串poolSize为50,线程数1000,循环次数3,测试不通过,出现超时问题,利用info clients命令查看Redis客户端连接数为51(50是应用程序的,1是我通过命令连接的)

.Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 .Net Core Web Api实践(四)填坑连接Redis时Timeout performing EVAL

 

 

 

连接串poolSize为100,线程数1000,循环数次数3,客户端连接数27,测试通过

连接串poolSize为100,线程数3000,循环数次数3,客户端连接数46,测试通过

连接串poolSize为100,线程数5000,循环数次数3,客户端连接数42,测试通过

连接串poolSize为100,线程数8000,循环数次数3,客户端连接数101,测试不通过

 

由此可见,不断调高线程数的情况下,应用程序还是会崩溃,但是poolSize设为100基本就够用了,假设产品用户量为100万,日活20万,最高同时在线用户3万,单服务入口最高1万访问量,上面压力测试发现是可以应对15000的同时访问量的。当然poolSize也可以设置得更高,毕竟Redis允许的最大客户端连接数是10000,在没有迹象表明poolSize设置较大值不会有任何负面作用的情况下,个人觉得不宜盲目调大。另外有兴趣的同学也可以相对的做下预警机制,比如poolSize设置了100,当Redis客户端连接数达到80时,向IT人员发送短信预警,届时可以调高poolSize值,避免系统崩溃。

6、结语

到这篇文章结束,.net core+Redis+Docker+k8s(或IIS+nginx)实现Session共享才算真正完结,建议这篇文章跟前两篇文章一起看,Redis连接超时的坑,算是最大的坑之一,所以前后花了这么多篇幅介绍,如果文章中哪些错误或值得改进的地方,也欢迎大家指出。

 

 

参考资料:

1、CSRedisCache实现:  https://github.com/2881099/Microsoft.Extensions.Caching.CSRedis/blob/master/CSRedisCache.cs

2、Jemeter使用:https://www.cnblogs.com/monjeo/p/9330464.html

3、StackExchange.Redis官方介绍: https://stackexchange.github.io/StackExchange.Redis/PipelinesMultiplexers

一次线上故障:数据库连接池泄露后的思考

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享