redis記憶體相關配置conf

redis安裝在/usr/local/redis  

運行：cd  /usr/local/redis   -> ./redis-server &

測試：[root@chbjt redis]# ./redis-cli
                                           127.0.0.1:6379> set foo bar
                                           OK
                                           127.0.0.1:6379> get foo
                                           "bar"

# requirepass foobared去掉注釋，foobared改為自己的密碼，我在這裡改為888888

requirepass 888888

redis記憶體相關配置conf（摘自：http://tech.it168.com/a2011/0818/1234/000001234478_all.shtml ）

通過《redis五種資料類型的使用》,可以看出redis實際上的記憶體管理成本非常高，即佔用了過多的記憶體，所以提供了一系列的參數和手段來控制和節省記憶體。

首先最重要的一點是不要開啟Redis的VM選項，即虛擬記憶體功能，這個本來是作為Redis儲存超出實體記憶體資料的一種資料在記憶體與磁碟換入換出的一個持久化策略，

   但是其記憶體管理成本也非常的高，並且此種持久化策略並不成熟，所以要關閉VM功能，請檢查你的redis.conf檔案中 vm-enabled 為 no。

其次最好設定下redis.conf中的maxmemory選項，該選項是告訴Redis當使用了多少實體記憶體後就開始拒絕後續的寫入請求，1024*1024=1048576 bytes=1M

   該參數能很好的保護好你的Redis不會因為使用了過多的實體記憶體而導致swap,最終嚴重影響效能甚至崩潰。

另外Redis為不同資料類型分別提供了一組參數來控制記憶體使用量，

   Redis Hash是value內部為一個HashMap，如果該Map的成員數比較少，則會採用類似一維線性緊湊格式來儲存該Map, 即省去了大量指標的記憶體開銷，這個參數控制對應在redis.conf設定檔中下面2項：

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

hash-max-zipmap-entries含義是當value這個Map內部不超過多少個成員時會採用線性緊湊格式儲存，預設是64,即value內部有64個以下的成員就是使用線性緊湊儲存，超過該值自動轉成真正的HashMap。

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，可以根據自己的需要進行修改，修改後重新編譯就可以了。