Redis是開源、高性能的Key-value存儲(chǔ)引擎。

最近我們?cè)谝粋€(gè)日訪問量約1kw的網(wǎng)站上使用redis替換以前的memcache，成功將CPU從30%下降到15%，效果相當(dāng)顯著。

ServiceStackRedis是最受歡迎的C#驅(qū)動(dòng)之一。關(guān)于如何使用ServiceStackRedis請(qǐng)參見這里——使用ServiceStackRedis鏈接Redis簡(jiǎn)介

不過我們?cè)谑褂肧erviceStackRedis的線程池（PooledRedisClientManager）還是碰到了不少問題。

　1 鏈接數(shù)異常。

　一個(gè)webserver會(huì)占用80個(gè)鏈接。當(dāng)15臺(tái)webserver就過千了，這時(shí)會(huì)出現(xiàn)有些客戶端鏈接不上的情況。

　解決方案：

　GetInActiveWriteClient方法中

//找下一個(gè)目標(biāo)
//從當(dāng)前讀寫指針的后面開始查找，而不是從0開始
var?nextIndex?=?(WritePoolIndex?+?i)?%?writeClients.Length;
更改為
var?nextIndex?=?i;
同時(shí)修改DisposeClient方法中將readClient.Active?==?false將DisposeConnection一下。線程就能很好的回收了。

效果：
在我們這樣一個(gè)網(wǎng)站下，單臺(tái)webserver大約會(huì)占用10個(gè)~15個(gè)鏈接，比之前的80個(gè)少了不少。

分析：

從代碼上來看，作者的初衷是為了更快的找到空閑的線程，但是卻認(rèn)所有線程都不間斷的使用，沒有一個(gè)線程可能空閑。
如果站點(diǎn)較小，webserver不太多，不改問題也不大。不過我認(rèn)為用長(zhǎng)鏈接并不劃算，因?yàn)榕credis建立一個(gè)鏈接還是相對(duì)比較“便宜”的。

2 多臺(tái)redis存儲(chǔ)相同的內(nèi)容。

相同的內(nèi)容會(huì)冗余在所有redis中

解決方案

在GetInActiveWriteClient中加入int型參數(shù)來標(biāo)識(shí)出使用那臺(tái)redis

var?start?=?0;
var?step?=?1;
if?(index?>?-1?&&?index?<?ReadWriteHosts.Count)
{
　　start?=?index;
　　step?=?ReadWriteHosts.Count;
}
//遍歷讀寫池
//這個(gè)時(shí)候池是鎖定的
for?(var?i?=?start;?i?<?writeClients.Length;?i?+=?step)
{
　　省略

這樣線程池中就會(huì)按ReadWriteHosts的個(gè)數(shù)來順序分配。

效果：

在進(jìn)行讀寫時(shí)只需要使用key.GetHashCode方法獲得一個(gè)hash值就能準(zhǔn)確分配到其中一臺(tái)redis上。保證所有的redis的數(shù)據(jù)不重復(fù)。



與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的ServiceStack.Redis的问题与修正的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。