前言：前两篇文章 .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版本还会不会有这个问题。

3、问题重现

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

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

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

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

5、解决方案

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

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

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
修改Startup.cs的注册方式如下：
这里的defaultdatabase貌似只能设置为0，设置为其它值会报错，这点不如Microsoft.Extensions.Caching.Redis。
测试结果如下：
连接串poolSize为50，线程数500，循环次数3，测试通过（即Redis数据库成功缓存1500条数据，汇总报告中错误率为0）
连接串poolSize为50，线程数1000，循环次数3，测试不通过，出现超时问题，利用info clients命令查看Redis客户端连接数为51（50是应用程序的，1是我通过命令连接的）
连接串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值，避免系统崩溃。
到这篇文章结束，.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