原文鏈接： http://www.infoq.com/cn/articles/tq-redis-memory-usage-optimization-storage
Redis常見數據模型的使用場景以及在內存優化方面和性能優化方面的分析：
?
常見類型：String、 Hash、 set、 sorted set、 list ?五種。。。。。
?
五種數據類型是在內存管理中的描述：
?
首先Redis內部使用一個redisObject對象來表示所有的key和value，如下圖所講，type代表一個value對象具體是何種數據類型，encoding
是不同數據類型在redis內部的存儲方式，比如，type=string代表value存儲的是一個普通字符串，那么對應的encoding可以是raw或int，如果是int則代表實際redis內部是按數值類型存儲和表示這個type的string。。當然這個字符串本是可以用數值表示。
?
vm字段：redis的虛擬內存功能只有打開了，此字段才會真正的分配內存，該功能默認是關閉的。
?
?
分析五中數據類型的使用和內部實現方式：
?
String ：常用命令：set-- get---decr---incr---mget--等
應用場景：String是最常用的一種數據類型，普通的key'value存儲都可以歸為此類，
實現方式：String在redis內部默認是就是一個字符串，被redisObject所引用，當遇到incr，decr等操作時，會轉成數值型進行計算。此時的redisObject的encoding字段為int。
?
Hash ：常用命令----hget，hset，hgetall等
?
應用場景：用存儲一個用戶信息對象數據為例：
用戶ID為查找的key，存儲value用戶對象包含姓名，年齡，生日等信息。如果用普通的key，value結構來存儲，主要是下面兩種存儲方式：
?
?
這種方式將用戶ID作為查找key，把其他信息封裝成一個對象，以序列化的方式存儲，這種方式的缺點，增加了序列化\反序列化的開銷，并且在需要修改其中一項信息時，需要把整個對象取回，并且修改操作需要對并發進行保護，引入CAS等復雜問題。
?
?
?
?
?
上面的第二種方法是這個用戶信息對象有多少成員就存成多少個key-value對兒。用用戶ID+對應屬性的名稱作為以為標識來取得屬性的值。但這樣造成了ID重復存取。
?
?
這樣的話，使用Hash結構就可以更好的處理了：
?
Redis的hash實際是內部存儲的value為一個hashmap，并踢狗了直接存取這個Map成員的接口，如下圖：
?
?
這樣key仍然是用戶ID，value是一個Map，這個Map的key是成員的屬性名，value是屬性值。這樣 對數據的修改和存取都可以直接通過內部Map的key（Redis里稱內部map的key為field）。也就是通過key（用戶id）+field（屬性標簽）就可以操作對應的屬性數據了。既不需要重復存儲數據，也不會帶來序列化和并發修改控制的問題。
?
?
?
但這里需注意的是hgetall命令，這個接口命令可以取到全部的屬性數據，但是如果內部Map的成員很多，那么涉及到遍歷整個內部Map的操作，由于Redis單線程模型的緣故，這個遍歷操作可能會比較耗時。。
?
實現方式：
上面提到Redis的hash對應的內部value內部實際就是一個HashMap，而實際這里會有兩種不同實現，這個hash的成員比較少時，Redis為了節省內存會采用類似一維數組的方式來緊湊存儲，而不是真正的hashMap結構，對應的value redisObject 的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap。此時encoding為ht。
?
?
List ?：常用命令：lpush，rpush，lpop，rpop，lrange等。
?
應用場景：Redis list應用場景非常多，也是redis 的重要的數據結構之一。比如twitter的關注列表，粉絲列表都可以用redis的list結構來實現。
?
實現方式：redis的list實際是一個雙向鏈表 —— 即可以支持 反向查找和遍歷，更方面操作，不過帶來了部分額外的內存開銷，redis內部很多實現包括發送緩沖隊列等也都是用這個數據結構。
?
?
Set ：常用命令：sadd 、 spop、smembers，sunion等
?
應用場景：對外提供的功能與list類似是一個列表的功能。特殊之處，在于set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，并且set提供了判斷某個成員是否在一個set集合內的重要接口，這個也是list所不能提供的。
?
實現方式：set 的內部實現是一個value 永遠為nullHashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。
?
Sorted set ：常用命令：zadd、zrange、zrem、zcard等。
?
使用場景：使用與set類似。區別是set不是自動有序的。而sorted set可以通過用戶額外提供一個優先級score 的參數來為成員排序，并且插入是有序的。即自動排序。當你需要一個有序的并且不重復的集合列表，那么可以選擇sorted set數據結構。比如twitter的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排序的。
?
實現方式：redis sorted set的內部霍思燕那個hashMap和跳躍表（SkipList）來保證數據的存儲和有序，hashMap里放的是成員到score的映射，而跳躍表里存放的是所有的成員，排序依據的是hashMap里存放的score，使用跳躍表的結構可以獲得比較高的查找效率，并且在實現上比較簡單。
?
?
常用內存優化手段與參數：
通過上面的實現上的分析，可以看出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配置文件中下面兩項：
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
hash-max-zipmap-entres
?
含義是當value這個map內部不超過多少成員時會采用線性緊湊格式存儲，默認是64，即 alue內部有64個以下的成員就是使用線性緊湊存儲，超過該值就自動轉成真正的hashMap。
hash-max-zipmap-value 含義是當alue 這個map內部的每個成員值長度不超過多少字節就會采用線性緊湊存儲來節省空間。
以上兩個條件，任意一條超過設置就會轉成真正的hashmap，也就不會再節省內存了，那么這個值是不是設置的越大越好呢。答案當然是否定的，hashmap的優勢就是查找和操作的時間復雜度都是o(1)的，而放棄hash采用一維存儲則是o(n)的時間復雜度，如果成員數量很少，則影響不大，否則嚴重影響性能，所以要權衡這個值的設置?？傮w上是最根本的時間成本和空間成本上的權衡。
?
同類參數還有：
list-max-ziplist-entries 512
說明：list數據類型多少節點以下會采用去指針的緊湊存儲格式。
?
list-max-ziplist-value 64
說明：list數據類型節點值大小系哦啊與多少字節會采用緊湊存儲格式。
set-max-inset-entries 512
說明set數據類型內部數據如果全部是數值型，且包含多少字節點以下，會采用緊湊存儲格式。
?
redis內部實現沒有對內存分配方面做過多的優化，一定程度上回存在內存碎片，不過大多數的情況下，這個不會成為redis的性能瓶頸。不過如果在redis內部存儲的大部分是數值型的話，redis內部采用了一個shared integer的方式來省去分配內存的開銷，即在系統啟動是先分配一個從1~n那么多個數值對象放在一個池子中，如果存儲的數據恰好是這個數值范圍內的數據，則直接誒從池子里取出對象。并且通過引用技術的方式來分享。這樣在系統存儲了大量數值下，也能在一定程度上節省內存并且提高ixngneng，這個參數值n的設置需要修改源代碼中的一行宏定義：REDIS_SHARED_INTERGERS，該值默認為10000，可以根據自己的需要進行修改，修改后重新編譯就可以了。
?
?
redis的持久化機制:
?
四種持久化方式：
定時快照方式---snapshot----------定時器事件---固定時間點檢查當前數據發生的改變次數與時間是否滿足觸發持久化的條件。滿 足時，就通過fork調用來創建一個子進程。
這個子進程默認會與父進程共享相同的地址空間，這時就可以通過子進程來遍歷整個內存來進行存儲操作，而主進程則仍然可 以提供服務，當有寫入時由操作系統按照內存頁(page)為單位來進行copy-on-write保證父子進程之間不會互相影響。
該持久化的主要 缺點是定時快照只是代表一段時間內的內存映像，所以系統重啟會丟失上次快照與重啟之間所有的數據
基于語句追加文件的方式------aof-------類似mysql基于語句的binlog方式，即每條會使redis內存數據發生改變的命令都會追加到 一個log文件中，也就是說這個log文件就是redis的持久化數據。
缺點是：追加log文件可能導致體積過大，當系統重啟恢復數據時如果是aof的方式則加載數據會非常緩慢
虛擬內存----vm--------已被遺棄。。。。
Diskstore方式-------B-tree
?
?
設計思路上，前兩種基于全部數據都在內存中，即小數據量下提供磁盤落地功能。
? ? 后兩種方式則是作者在嘗試存儲數據超過物理內存時，即大數據量的數據存儲。仍在實驗階段
?
?
?
redis持久化磁盤IO方式及其帶來的問題。
?
?
redis 崩潰的一個原因：
redis的持久化使用了buffer IO造成的，所謂buffer IO指redis對持久化文件的寫入和讀取操作都會使用物理內存page cache 而大多數數據庫系統會使用direct IO來繞過這層page cache 并自行維護一個數據cache，。而當redis的持久化文件過大,尤其是快照文件。并對其讀寫時，磁盤文件中數據都會被加載到物理內存中作為操作系統對該文件的一層的cache。而這層cache的數據與redis內存中管理的數據實際是重復存儲的，雖然內核在物理內存緊張時會做page cache 的剔除工作，
?但內核很可能會認為某個page cache 會更重要，而讓你的進程開始swap，這時你的系統就會開始出現不穩定或者崩潰了。
補充：
page cache，又稱pcache，其中文名稱為
頁高速緩沖存儲器
，簡稱頁高緩
。page cache的大小為一頁，通常為4K。在linux讀 寫文件時，它用于緩存文件的邏輯內容，從而加快對磁盤上映像和數據的訪問。
經驗：當你的redis物理內存使用超過內存總容量的3/5，就會開始比較危險了
?
?
總結：
1、根據業務需要選擇核實的數據類型，并為不同的應用場景設置相應的緊湊存儲參數
?
2、當業務場景不需要數據持久化時，關閉所有的持久化方式可以獲得最佳的性能以及做大的內存使用量。
?
3、如果需要持久化，根據是否可以容忍重啟丟失部分數據在快照方式與語句追加方式之間選擇其一，不要使用虛擬內存以及diskstore方式
?
4、不要讓你的redis所在機器物理內存使用超過實際內存總量的3/5。。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
