StackExchange.Redis Timeout performing 超時問題

最近在作的一個項目，用的.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, serverEndpoint: 172.16.3.119:6379, mgr: 10 of 10 available, clientName: s-119, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=120,Free=32747,Min=1,Max=32767), v: 2.0.571.20511(Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts))

後面是堆棧信息.....

蛋疼了好久，搜了不少文章，獲得如下

解決方案

一、換掉，不用這個驅動（ 能夠看看.net core redis 驅動推薦，爲何不使用 StackExchange.Redis）

二、redis操做修改成所有異步&& ThreadPool.SetMinThreads(200, 200);

我用的第二種解決了問題，主要換驅動也可能遇到坑；還有時間成本問題；

緣由簡析

咱們看到以上的異常信息當中有這麼一段：

IOCP: (Busy=0,Free=1000,Min=1,Max=1000),

WORKER: (Busy=120,Free=32747,Min=1,Max=32767),

意思是當前繁忙的WORKER 線程有120個，而系統「要由線程池根據須要建立的新的最小工做程序線程數。」，也就是系統建立的工做線程數不足以知足redis的Get操做的繁忙線程的需求，致使部分Get操做的線程堵塞超時了；

因此咱們把「最小線程workerThreads」 修改成200解決問題；

200是我估摸着生產環境服務器設置的，該值設置不合理有可能致使性能問題；