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

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

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

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

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

（1）找到 Redis 组件注入的地方

（2）查看 AddDistributedRedisCache 源码，发现注入的是一个单例的 IDistributedCache 对象：

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

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

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

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

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

（2）使用CSRedis组件，替代 Microsoft.Extensions.Caching.Redis ，具体实现方式如下：
安装 nuget 包

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

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;
对照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、环境及工具准备操作系统：windows10数据库：Redis压力测试工具：JMeter（传送门）2、背景介绍项目迁移到.net core并上线以后，运行没多久接口就频繁罢工，容器没有挂，redis、mogodb、sql server全都正常，容器重启后可以正常一下，但是没过多久就又罢工了，最后只有通过docker logs命令挨个去寻找容器日志中记录的错误信息，结果发现了StackExchange.Redis.RedisTimeoutException: Timeout performing 
				
我们项目用地StackExchange.Redis，在高并发下会有超时的报错提示。搞了好就，最终处理好了，赶紧记录一下，压压惊！
1、设置最小线程池（ThreadPool.SetMinThreads(200, 200)），网上大多都这么说的，官网也是这么说的。这样表面上是可以解决超时问题的，但是线程太多会也影响CPU的运行效率的。最终会降低系统性能，是个治标不治本的办法。
2、换Reid...
				
Meiam.System-.NET 5 / .NET Core 3.1 WebAPI + Vue 2.0 + RBAC企业级前替代分离权限框架
主-.NET 5 / netcore31-.NET Core 3.1
演示地址：  :
运行环境：CENTOS7 / .NET 5 / MYSQL-后台用户9999密码123456
给个星星！  :white_medium_star:
如果你喜欢这个项目或者它帮助你，请给Star〜（辛苦咯）
采用服务+接口的形式封装框架（可移除的仓库层）
采用REDIS存储会话（用户信息/用户权限）-更好的支持分布式应用，用户踢出，登录登出等功能
采用Autofac依赖注入IoC容
				
1、是一个简单的购物商场购物车实例，通过 .NET Core 3.1 实现基本购物网站购物车相关模拟业务
2、EF Core实现实体类，WebAPI实现业务操作，mvc实现页面展示
3、需要安装.NET Core 3.1，Redis，并且在vs2019实现的代码
				
最近在做的一个项目，用的.net core 2.1,然后缓存用的Redis，缓存相关封装是同事写的，用的驱动是StackExchange.Redis version 2.0.571 ，一直听说这个驱动并发情况下有TimeOut bug，项目开发差不多后，我压测了一下，简单的模拟30个用户持续访问某一个有用到缓存的查询接口，结果这么小的压力下超时异常出现：
Timeout performing GET my_141 (5000ms), inst: 30, qu: 0, qs: 20, in: 20320, s
				
- 连接超时: 指的是客户端实现到远端机器端口的连接时，等待的秒数
- 读取超时：指的是客户端等待服务器发送请求的时间。（特定地，它指的是客户端要等待服务器发送字节之间的时间。在 99.9% 的情况下这指的是服务器发送第一个字节之前的时间）
 读取超时是没有默认值的，如果不设置，程序将一直处于等待状态。
				
`spring.redis.timeout` 是 Spring Boot 中 Redis 相关配置参数之一，它的作用是设置 Redis 连接的超时时间。具体来说，它表示在与 Redis 服务器建立连接时的超时时间，单位是毫秒。如果连接超时，则会抛出连接异常。
在实际应用中，如果 Redis 服务器响应较慢或者网络延迟较高，可以通过设置适当的 `spring.redis.timeout` 参数值来避免长时间等待连接建立。一般来说，建议将超时时间设置为几秒钟，根据实际情况进行调整。
例如，以下是一个 Spring Boot 应用程序中配置 Redis 连接超时时间为 5 秒的示例：
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.timeout=5000