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