Redis存儲及容災策略

Redis利用內存發揮的高性能讀寫在不少場景下大有所爲，可是Redis自己畢竟仍是一個單機數據庫，若是系統對其屬於強依賴，那麼仍是必須作好必要的容災，針對這個問題，有如下幾種策略：

1、M/S切換

因爲Redis是單機數據庫，因此針對MySQL的一些容災方案也能順利適用，例如當Redis意外宕機，能夠將請求立刻切到備庫，同時快速恢復數據。

2、AOF

Redis有兩種持久化的方式，分別是SnapShotting和Append-Only File，其原理和特性能夠參考《對redis數據持久化的一些想法》一文，總得來講，快照對性能影響更小，也只會備份須要的數據，但兩次快照中間的數據是無法保證必定會持久化的。

相比之下AOF的粒度更細，持久化效果更好，相似於MySQL的BinLog，缺點是會損失一部分性能，並且會記錄沒必要要的日誌，這一點當系統運行時間很長時會特別突出，也許恢復全部數據原本只要1個小時，卻可能要花100甚至1000小時去搞。

3、讀取數據源直接恢復

這個方案是和業務場景相關的，因爲以前某個項目中Redis起到了存放索引的做用，因此利用MySQL的數據能夠容易地從新創建Redis的全部內容，這裏能夠臨時搞一個Trigger，不斷讀MySQL寫Redis，利用MySQL的順序讀和Redis高TPS的特性，實踐中，能夠在幾分鐘內重建上千萬的數據量。

目前Redis在功能上一般仍用於Cache，若是須要保證HA的持久化存儲，請考慮具體場景，此外也能夠考慮是否可使用原生分佈式的memcached或升級硬件（如SSD、Fusion-IO）加強原有DB的性能。

 

 

 

個人應用裏爲了保證高性能，數據沒有作dump，也沒有用aof。由於不作dump發生的故障遠遠低於作dump的時候，即便數據丟失了，自動修復腳本能夠立刻數據恢復。畢竟對海量數據redis只能作數據分片，那麼落到每一個節點上的數據量也不會不少。

redis的虛擬內存建議也不要用，用redis原本就是爲了達到變態的性能，虛擬內存、aof看起來都有些雞肋。

如今還離不開redis，由於它的mget是如今全部db裏性能最好的，之前也考慮過用tokyocabinet hash方式作mget，性能不給力。直接用redis，基本上單個redis節點mget能夠達到10W/s

 

http://lkf0217.iteye.com/blog/1076700

從這個圖中能夠看出：

　　1) 對於沒有持久化的方式，讀寫都在數據量達到800萬的時候，性能降低幾倍，此時正好是達到內存10G，Redis開始換出到磁盤的時候。而且從那之後再也沒辦法從新振做起來，性能比Mongodb還要差不少。

　　2) 對於AOF持久化的方式，整體性能並不會比不帶持久化方式差太多，都是在到了千萬數據量，內存佔滿以後讀的性能只有幾百。

　　3) 對於Dump持久化方式，讀寫性能波動都比較大，可能在那段時候正在Dump也有關係，而且在達到了1400萬數據量以後，讀寫性能貼底了。在Dump的時候，不會進行換出，並且全部修改的數據仍是建立的新頁，內存佔用比平時高很多，超過了15GB。並且Dump還會壓縮，佔用了大量的CPU。也就是說，在那個時候內存、磁盤和CPU的壓力都接近極限，性能不差纔怪。

　　總結一下：

　　1) Redis其實只適合做爲緩存，而不是數據庫或是存儲。它的持久化方式適用於救救急啥的，不太適合看成一個普通功能來用。對於這個版本的Redis，不建議使用任何的持久化方式。不然到時候可能會死的比較難看。說白了，指望Redis是memcached的升級版，帶有各類數據結構，可是不要指望 Redis來和Mongodb/Kt等來比。

　　2) 對於VM其實也是不建議開啓，雖然開啓VM可讓Redis保存比內存更多的數據，可是若是冷熱數據不是很明顯的話性能會很是差(個人測試都是隨機查詢 Key，冷熱不明顯)。固然，對於冷熱明顯的狀況下能夠設置200% - 400%的內存做爲VM空間，也不建議設置10倍的內存空間做爲VM(像個人配置同樣)。

　　3) ServiceStack.Redis客戶端好像有幾個Bug，首先RedisTypedClient的Dispose竟然沒有實現，應該是要調用 client.Dispose()，其次RedisNativeClient的Info屬性不是每次都獲取最新值的，第三 PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加沒看到減的地方，也不知道這是幹啥的，其實每次都取第一個不是Active的Client就能夠了，PooledRedisClientManager也沒有把超時使用的Active的 Client強制回收(避免使用的時候忘記Dispose佔用過多的鏈接)。有關這幾點，我會嘗試聯繫ServiceStack.Redis的做者。