redis經常使用優化及持久化到硬盤

經常使用內存優化手段與參數

redis的性能如何是徹底依賴於內存的，因此咱們須要知道如何來控制和節省內存。

首先最重要的一點是不要開啓Redis的VM選項，即虛擬內存功能，這個原本是做爲Redis存儲超出物理內存數據的一種數據在內存與磁盤換入換出的一個持久化策略，可是其內存管理成本很是的高，因此要關閉VM功能，請檢查你的redis.conf文件中 vm-enabled 爲 no。

其次最好設置下redis.conf中的maxmemory選項，該選項是告訴Redis當使用了多少物理內存後就開始拒絕後續的寫入請求，該參數能很好的保護好你的Redis不會由於使用了過多的物理內存而致使swap,最終嚴重影響性能甚至崩潰。

另外Redis爲不一樣數據類型分別提供了一組參數來控制內存使用，咱們知道Redis Hash是value內部爲一個HashMap，若是該Map的成員數比較少，則會採用相似一維線性的緊湊格式來存儲該Map, 即省去了大量指針的內存開銷，這個參數控制對應在redis.conf配置文件中下面2項：

hash-max-zipmap-entries 64 
hash-max-zipmap-value 512 

1·  含義是當value這個Map內部不超過多少個成員時會採用線性緊湊格式存儲，就至關於Map裏面存Map，默認是64，即value內部有      64個如下的成員就是使用線性緊湊存儲，超過該值自動轉成真正的HashMap。

2·  hash-max-zipmap-value 含義是當 value這個Map內部的每一個成員值長度不超過多少字節就會採用線        性緊湊存儲來節省空間。

以上2個條件任意一個條件超過設置值都會轉換成真正的HashMap，也就不會再節省內存了，那麼這個值是否是設置的越大越好呢，答案固然是否認的，
HashMap的優點就是查找和操做的時間複雜度都是O(1)的，而放棄Hash採用一維存儲則是O(n)的時間複雜度，若是成員數量不多，則影響不大，不然會嚴重影響性能，因此要權衡好這個值的設置，整體上仍是最根本的時間成本和空間成本上的權衡。

一樣相似的參數還有：

list-max-ziplist-entries 512
說明：list數據類型多少節點如下會採用去指針的緊湊存儲格式。

list-max-ziplist-value 64 
說明：list數據類型節點值大小小於多少字節會採用緊湊存儲格式。

set-max-intset-entries 512 
說明：set數據類型內部數據若是所有是數值型，且包含多少節點如下會採用緊湊格式存儲。

Redis內部實現沒有對內存分配方面作過多的優化，在必定程度上會存在內存碎片，不過大多數狀況下這個不會成爲Redis的性能瓶頸， 不過若是在Redis內部存儲的大部分數據是數值型的話，Redis內部採用了一個shared integer的方式來省去分配內存的開銷， 即在系統啓動時先分配一個從1~n 那麼多個數值對象放在一個池子中，若是存儲的數據剛好是這個數值範圍內的數據，則直接從池子裏取出該對象， 而且經過引用計數的方式來共享，這樣在系統存儲了大量數值下，也能必定程度上節省內存而且提升性能， 這個參數值n的設置須要修改源代碼中的一行宏定義REDIS_SHARED_INTEGERS，該值默認是10000，能夠根據本身的須要進行修改，修改後從新編譯就能夠了。