我们在.net core 3.1与azure redis缓存的集成中遇到问题。引发的异常为
执行请求时发生未处理的异常。“，”@l“：”error“，”@x“：”stackexchange.redis.redistimeoutexception:等待响应超时（出站=1403kib，入站=5657kib，已用15000ms，超时为15000ms），command=eval，next:eval，inst:0，qu:0，qs:709，aw:true，rs:readasync，ws:writing，in:0，服务端点：redis-scr-mns-dev.redis.cache.windows。net:6380，mc:1/1/0，mgr:10/10可用，clientname:，iocp:（忙=0，空闲=1000，最小=4，最大=1000），worker:（忙=7，空闲=32760，最小=4，最大=32767），v:2.1.58.34321（请参阅本文，了解一些可能导致超时的常见客户端问题：https://stackexchange.github.io/stackexchange.redis/timeouts)
是的，我已经读过这篇文章了，我们正在使用stackexchange.redis nuget包，最新版本。我们已经采取的步骤是
使用多个值设置最小线程池计数（threadpool.setminthreads（short.maxvalue，short.maxvalue）；）
将redis timeout值从默认的5秒增加到15秒（说实话，再高一点也解决不了问题，因为您会读得更深入一些：）
你问的是什么设置？
.net core 3.1 rest api在最新的iis上运行，在具有16gb ram的4核windows服务器上具有3个工作线程设置（在cpu或内存的监控方面没有看到任何极端情况）
已连接到azure redis缓存。目前运行的基本c5具有高网络带宽和23gb内存（以前是较低的，所以我们尝试扩展这个）
最后将请求推送到azure服务总线（没有问题）
一个批处理进程正在运行和处理10000个api调用（几个api），其中的一个在redis缓存上崩溃，出现超时异常。其他api运行正常，没有超时，但当前正在连接到不同的redis缓存（只是为了隔离此api的行为）所有api和/或批处理程序都使用具有缓存实现的自定义nuget包，因此我们确信这不会是该1 api（所有共享代码）中的实现问题。
我们如何使用缓存？好吧，通过依赖注入，我们注入isharedcachestore，这只是我们自己的接口，我们把它放在idistributedcache之上，以确保只有异步调用可用，还有rediscache，这是使用redis实现的（isharedcachestore是为了将来使用其他缓存机制）我们使用microsoft.extensions.caching.stackexchangeredis，版本3.1.5，启动时注册是

services.Configure<CacheConfiguration>(options => configuration?.GetSection("CacheConfiguration").Bind(options))
            .AddStackExchangeRedisCache(s =>
                {
                    s.Configuration = connectionString;
                })
            .AddTransient<IRedisCache, RedisCache>()
            .AddTransient<ISharedCacheStore, SharedCacheStore>();

老实说，我们没有主意了。我们看不到azure中的redis缓存示例有任何问题，因为当我们得到超时时，这个示例甚至还没有接近它的顶部。在较低的定价计划中，服务器负载达到80%左右，而在较高的定价计划中，服务器负载甚至没有达到当前计划的10%。
根据insights的数据，我们在运行时每分钟有4000次缓存命中，导致了大约10%的服务器负载。
更新：值得一提的是，批处理和api现在运行在本地环境中，而不是云环境。移动到云计算是计划在未来几个月。这也适用于其他api连接到redis缓存而不给出问题
比较
另一个azureredis缓存在没有任何问题的情况下（从本地）每分钟获得45k次点击
这一次甚至达到了每分钟10公里的命中率