Redis的幾點積累

1.Redis比memcache快

　　Redis具備事務，持久化等機制，可是它還能作到高性能，緣由包括以下：

• Libevent。和Memcached不一樣，Redis並無選擇libevent。Libevent爲了迎合通用性形成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平臺的很多性能。Redis用libevent中兩個文件修改實現了本身的epoll event loop(4)。業界很多開發者也建議Redis使用另一個libevent高性能替代libev，可是做者仍是堅持Redis應該小巧並去依賴的思路。一個印象深入的細節是編譯Redis以前並不須要執行./configure。
• CAS問題。CAS是Memcached中比較方便的一種防止競爭修改資源的方法。CAS實現須要爲每一個cache key設置一個隱藏的cas token，cas至關value版本號，每次set會token須要遞增，所以帶來CPU和內存的雙重開銷，雖然這些開銷很小，可是到單機10G+ cache以及QPS上萬以後這些開銷就會給雙方相對帶來一些細微性能差異。

2.VM特性

　　從2.0版本開始，Redis提供虛擬內存支持。

　　Redis的數據所有放在內存帶來了高速的性能，可是也帶來一些不合理之處。好比一箇中型網站有100萬註冊用戶，若是這些資料要用Redis來存儲，內存的容量必須可以容納這100萬用戶。可是業務實際狀況是100萬用戶只有5萬活躍用戶，1周來訪問過1次的也只有15萬用戶，所以所有100萬用戶的數據都放在內存有不合理之處，RAM須要爲冷數據買單。

　　這跟操做系統很是類似，操做系統全部應用訪問的數據都在內存，可是若是物理內存容納不下新的數據，操做系統會智能將部分長期沒有訪問的數據交換到磁盤，爲新的應用留出空間。現代操做系統給應用提供的並非物理內存，而是虛擬內存(Virtual Memory)的概念。

　　Redis的VM依照以前的epoll實現思路依舊是本身實現。可是在前面操做系統的介紹提到OS也能夠自動幫程序實現冷熱數據分離，Redis只須要OS申請一塊大內存，OS會自動將熱數據放入物理內存，冷數據交換到硬盤，另一個知名的「理解了現代操做系統(3)」的Varnish就是這樣實現，也取得了很是成功的效果。

　　做者antirez在解釋爲何要本身實現VM中提到幾個緣由(6)。主要OS的VM換入換出是基於Page概念，好比OS VM1個Page是4K, 4K中只要還有一個元素即便只有1個字節被訪問，這個頁也不會被SWAP, 換入也一樣道理，讀到一個字節可能會換入4K無用的內存。而Redis本身實現則能夠達到控制換入的粒度。另外訪問操做系統SWAP內存區域時block進程，也是致使Redis要本身實現VM緣由之一。

　　可是因爲其仍然涉及磁盤io，故2.6版本後再也不提倡，性能問題。

3.多使用hash類型

　　做爲一個key value存在，不少開發者天然的使用set/get方式來使用Redis，實際上這並非最優化的使用方法。尤爲在未啓用VM狀況下，Redis所有數據須要放入內存，節約內存尤爲重要。

假如一個key-value單元須要最小佔用512字節，即便只存一個字節也佔了512字節。這時候就有一個設計模式，能夠把key複用，幾個key-value放入一個key中，value再做爲一個set存入，這樣一樣512字節就會存放10-100倍的容量。

4.使用aof代替snapshot

　　Redis有兩種存儲方式，默認是snapshot方式，實現方法是定時將內存的快照(snapshot)持久化到硬盤，這種方法缺點是持久化以後若是出現crash則會丟失一段數據。所以在完美主義者的推進下做者增長了aof方式。aof即append only mode，在寫入內存數據的同時將操做命令保存到日誌文件，在一個併發更改上萬的系統中，命令日誌是一個很是龐大的數據，管理維護成本很是高，恢復重建時間會很是長，這樣致使失去aof高可用性本意。另外更重要的是Redis是一個內存數據結構模型，全部的優點都是創建在對內存複雜數據結構高效的原子操做上，這樣就看出aof是一個很是不協調的部分。

　　其實aof目的主要是數據可靠性及高可用性，在Redis中有另一種方法來達到目的：Replication。因爲Redis的高性能，複製基本沒有延遲。這樣達到了防止單點故障及實現了高可用。