從圖中可以猜測(cè)到還會(huì)有Redis 2.2.1 的
測(cè)試，相同的測(cè)試環(huán)境，1K的數(shù)據(jù)量，使用ServiceStack.Redis客戶端進(jìn)行如下測(cè)試：
1) Set操作
2) Get操作
3) Del操作
每一套測(cè)試分別使用三個(gè)配置進(jìn)行測(cè)試：
1) 綠色線條的是開(kāi)啟Dump方式的持久化，5分鐘持久化一次
2) 藍(lán)色線條是開(kāi)啟AOF方式的持久化，每秒寫入磁盤一次
3) 紅色線條是關(guān)閉任何的持久化方式
對(duì)于每一個(gè)配置都使用相同的其他配置：
1) 開(kāi)啟VM 最大內(nèi)存10GB(128字節(jié)一頁(yè))之后開(kāi)始換出，VM空間160GB
2) 最大使用內(nèi)存15GB，確保在Dump的時(shí)候有足夠的剩余內(nèi)存
3) 開(kāi)啟壓縮，沒(méi)有配置主從
現(xiàn)在來(lái)看一下測(cè)試結(jié)果：
從這個(gè)圖中可以看出：
1) 對(duì)于沒(méi)有持久化的方式，讀寫都在數(shù)據(jù)量達(dá)到800萬(wàn)的時(shí)候，性能下降幾倍，此時(shí)正好是達(dá)到內(nèi)存10G，Redis開(kāi)始換出到磁盤的時(shí)候。并且從那以后再也沒(méi)辦法重新振作起來(lái)，性能比Mongodb還要差很多。
2) 對(duì)于AOF持久化的方式，總體性能并不會(huì)比不帶持久化方式差太多，都是在到了千萬(wàn)數(shù)據(jù)量，內(nèi)存占滿之后讀的性能只有幾百。
3) 對(duì)于Dump持久化方式，讀寫性能波動(dòng)都比較大，可能在那段時(shí)候正在Dump也有關(guān)系，并且在達(dá)到了1400萬(wàn)數(shù)據(jù)量之后，讀寫性能貼底了。在Dump的時(shí)候，不會(huì)進(jìn)行換出，而且所有修改的數(shù)據(jù)還是創(chuàng)建的新頁(yè)，內(nèi)存占用比平時(shí)高不少，超過(guò)了15GB。而且Dump還會(huì)壓縮，占用了大量的CPU。也就是說(shuō)，在那個(gè)時(shí)候內(nèi)存、磁盤和CPU的壓力都接近極限，性能不差才怪。
總結(jié)一下：
1) Redis其實(shí)只適合作為緩存，而不是
數(shù)據(jù)庫(kù)或是存儲(chǔ)。它的持久化方式適用于救救急啥的，不太適合當(dāng)作一個(gè)普通功能來(lái)用。對(duì)于這個(gè)版本的Redis，不建議使用任何的持久化方式。否則到時(shí)候可能會(huì)死的比較難看。說(shuō)白了，期望Redis是memcached的升級(jí)版，帶有各種數(shù)據(jù)結(jié)構(gòu)，但是不要期望Redis來(lái)和Mongodb/Kt等來(lái)比。
2) 對(duì)于VM其實(shí)也是不建議開(kāi)啟，雖然開(kāi)啟VM可以讓Redis保存比內(nèi)存更多的數(shù)據(jù)，但是如果冷熱數(shù)據(jù)不是很明顯的話性能會(huì)非常差(我的測(cè)試都是隨機(jī)查詢Key，冷熱不明顯)。當(dāng)然，對(duì)于冷熱明顯的情況下可以設(shè)置200% - 400%的內(nèi)存作為VM空間，也不建議設(shè)置10倍的內(nèi)存空間作為VM(像我的配置一樣)。
3) ServiceStack.Redis客戶端好像有幾個(gè)
Bug，首先RedisTypedClient的Dispose居然沒(méi)有實(shí)現(xiàn)，應(yīng)該是要調(diào)用client.Dispose()，其次RedisNativeClient的Info屬性不是每次都獲取最新值的，第三PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加沒(méi)看到減的地方，也不知道這是干啥的，其實(shí)每次都取第一個(gè)不是Active的Client就可以了，PooledRedisClientManager也沒(méi)有把超時(shí)使用的Active的Client強(qiáng)制回收(避免使用的時(shí)候忘記Dispose占用過(guò)多的連接)。