.Net Core Web Api实践（四）填坑连接Redis时Timeout performing EVAL（.net是干嘛的）

前言：前两篇文章.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）

4、问题分析过程

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

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

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

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

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

5、解决方案

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

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

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

安装nuget包

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。