Redis常見數(shù)據(jù)模型的使用場景以及在內(nèi)存優(yōu)化方面和性能優(yōu)化方面的分析：

?

常見類型：String、 Hash、 set、 sorted set、 list ?五種。。。。。

?

五種數(shù)據(jù)類型是在內(nèi)存管理中的描述：

?

首先Redis內(nèi)部使用一個redisObject對象來表示所有的key和value，如下圖所講，type代表一個value對象具體是何種數(shù)據(jù)類型，encoding

是不同數(shù)據(jù)類型在redis內(nèi)部的存儲方式，比如，type=string代表value存儲的是一個普通字符串，那么對應(yīng)的encoding可以是raw或int，如果是int則代表實際redis內(nèi)部是按數(shù)值類型存儲和表示這個type的string。。當(dāng)然這個字符串本是可以用數(shù)值表示。

?

vm字段：redis的虛擬內(nèi)存功能只有打開了，此字段才會真正的分配內(nèi)存，該功能默認(rèn)是關(guān)閉的。

?

分析五中數(shù)據(jù)類型的使用和內(nèi)部實現(xiàn)方式：

?

String ：常用命令：set-- get---decr---incr---mget--等

應(yīng)用場景：String是最常用的一種數(shù)據(jù)類型，普通的key'value存儲都可以歸為此類，

實現(xiàn)方式：String在redis內(nèi)部默認(rèn)是就是一個字符串，被redisObject所引用，當(dāng)遇到incr，decr等操作時，會轉(zhuǎn)成數(shù)值型進行計算。此時的redisObject的encoding字段為int。

?

Hash ：常用命令----hget，hset，hgetall等

?

應(yīng)用場景：用存儲一個用戶信息對象數(shù)據(jù)為例：

用戶ID為查找的key，存儲value用戶對象包含姓名，年齡，生日等信息。如果用普通的key，value結(jié)構(gòu)來存儲，主要是下面兩種存儲方式：

?

這種方式將用戶ID作為查找key，把其他信息封裝成一個對象，以序列化的方式存儲，這種方式的缺點，增加了序列化\反序列化的開銷，并且在需要修改其中一項信息時，需要把整個對象取回，并且修改操作需要對并發(fā)進行保護，引入CAS等復(fù)雜問題。

?

?

?

?

?

?

上面的第二種方法是這個用戶信息對象有多少成員就存成多少個key-value對兒。用用戶ID+對應(yīng)屬性的名稱作為以為標(biāo)識來取得屬性的值。但這樣造成了ID重復(fù)存取。

?

?

這樣的話，使用Hash結(jié)構(gòu)就可以更好的處理了：

?

Redis的hash實際是內(nèi)部存儲的value為一個hashmap，并踢狗了直接存取這個Map成員的接口，如下圖：

?

這樣key仍然是用戶ID，value是一個Map，這個Map的key是成員的屬性名，value是屬性值。這樣 對數(shù)據(jù)的修改和存取都可以直接通過內(nèi)部Map的key（Redis里稱內(nèi)部map的key為field）。也就是通過key（用戶id）+field（屬性標(biāo)簽）就可以操作對應(yīng)的屬性數(shù)據(jù)了。既不需要重復(fù)存儲數(shù)據(jù)，也不會帶來序列化和并發(fā)修改控制的問題。

?

?

?

但這里需注意的是hgetall命令，這個接口命令可以取到全部的屬性數(shù)據(jù)，但是如果內(nèi)部Map的成員很多，那么涉及到遍歷整個內(nèi)部Map的操作，由于Redis單線程模型的緣故，這個遍歷操作可能會比較耗時。。

?

實現(xiàn)方式：

上面提到Redis的hash對應(yīng)的內(nèi)部value內(nèi)部實際就是一個HashMap，而實際這里會有兩種不同實現(xiàn)，這個hash的成員比較少時，Redis為了節(jié)省內(nèi)存會采用類似一維數(shù)組的方式來緊湊存儲，而不是真正的hashMap結(jié)構(gòu)，對應(yīng)的value redisObject 的encoding為zipmap，當(dāng)成員數(shù)量增大時會自動轉(zhuǎn)成真正的HashMap。此時encoding為ht。

?

?

List ?：常用命令：lpush，rpush，lpop，rpop，lrange等。

?

應(yīng)用場景：Redis list應(yīng)用場景非常多，也是redis 的重要的數(shù)據(jù)結(jié)構(gòu)之一。比如twitter的關(guān)注列表，粉絲列表都可以用redis的list結(jié)構(gòu)來實現(xiàn)。

?

實現(xiàn)方式：redis的list實際是一個雙向鏈表 —— 即可以支持 反向查找和遍歷，更方面操作，不過帶來了部分額外的內(nèi)存開銷，redis內(nèi)部很多實現(xiàn)包括發(fā)送緩沖隊列等也都是用這個數(shù)據(jù)結(jié)構(gòu)。

?

?

Set ：常用命令：sadd 、 spop、smembers，sunion等

?

應(yīng)用場景：對外提供的功能與list類似是一個列表的功能。特殊之處，在于set是可以自動排重的，當(dāng)你需要存儲一個列表數(shù)據(jù)，又不希望出現(xiàn)重復(fù)數(shù)據(jù)時，set是一個很好的選擇，并且set提供了判斷某個成員是否在一個set集合內(nèi)的重要接口，這個也是list所不能提供的。

?

實現(xiàn)方式：set 的內(nèi)部實現(xiàn)是一個value 永遠為nullHashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內(nèi)的原因。

?

Sorted set ：常用命令：zadd、zrange、zrem、zcard等。

?

使用場景：使用與set類似。區(qū)別是set不是自動有序的。而sorted set可以通過用戶額外提供一個優(yōu)先級score 的參數(shù)來為成員排序，并且插入是有序的。即自動排序。當(dāng)你需要一個有序的并且不重復(fù)的集合列表，那么可以選擇sorted set數(shù)據(jù)結(jié)構(gòu)。比如twitter的public timeline可以以發(fā)表時間作為score來存儲，這樣獲取時就是自動按時間排序的。

?

實現(xiàn)方式：redis sorted set的內(nèi)部霍思燕那個hashMap和跳躍表（SkipList）來保證數(shù)據(jù)的存儲和有序，hashMap里放的是成員到score的映射，而跳躍表里存放的是所有的成員，排序依據(jù)的是hashMap里存放的score，使用跳躍表的結(jié)構(gòu)可以獲得比較高的查找效率，并且在實現(xiàn)上比較簡單。

?

?

常用內(nèi)存優(yōu)化手段與參數(shù)：

通過上面的實現(xiàn)上的分析，可以看出redis的內(nèi)存管理成本比較高，即占用了過多的內(nèi)存，redis的作者對這點也很清楚，所以提供了一系列的參數(shù)和手段來控制和節(jié)省內(nèi)存：

?

首先最重要的一點是不要開啟redis的vm選項，即虛擬內(nèi)存功能。這個本來是作為redis存儲超出物理內(nèi)存數(shù)據(jù)的一種數(shù)據(jù)在內(nèi)存與磁盤換入換出的一個持久化策略，但是其內(nèi)存管理成本也很搞，并且我們后續(xù)會分析此種持久化策略并不成熟，所以關(guān)閉vm功能，所以請設(shè)置redis.conf文件中 的vm-enabled 為no。

其次，最好設(shè)置下redis.conf中的maxmemory選項，該選項告訴redis當(dāng)使用了多少物理內(nèi)存后就開始拒絕后續(xù)的寫入請求，該參數(shù)能很好的保護好你的redis不會因為使用過多的物理內(nèi)存而導(dǎo)致swap，最紅嚴(yán)重影響性能甚至崩潰。

?

另外redis為不同數(shù)據(jù)類型分別提供了一組參數(shù)來控制內(nèi)存使用，我們前面詳細分析過redis hash是value內(nèi)部為一個hashmap，如果該map 的成員比較少，則會采用類似一維線性的緊湊格式來存儲該map，即省去了大量指針的內(nèi)存開銷，這個從拿書控制對應(yīng)在redis.conf配置文件中下面兩項：

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

hash-max-zipmap-entres

?

含義是當(dāng)value這個map內(nèi)部不超過多少成員時會采用線性緊湊格式存儲，默認(rèn)是64，即 alue內(nèi)部有64個以下的成員就是使用線性緊湊存儲，超過該值就自動轉(zhuǎn)成真正的hashMap。

hash-max-zipmap-value 含義是當(dāng)alue 這個map內(nèi)部的每個成員值長度不超過多少字節(jié)就會采用線性緊湊存儲來節(jié)省空間。

以上兩個條件，任意一條超過設(shè)置就會轉(zhuǎn)成真正的hashmap，也就不會再節(jié)省內(nèi)存了，那么這個值是不是設(shè)置的越大越好呢。答案當(dāng)然是否定的，hashmap的優(yōu)勢就是查找和操作的時間復(fù)雜度都是o(1)的，而放棄hash采用一維存儲則是o(n)的時間復(fù)雜度，如果成員數(shù)量很少，則影響不大，否則嚴(yán)重影響性能，所以要權(quán)衡這個值的設(shè)置。總體上是最根本的時間成本和空間成本上的權(quán)衡。

?

同類參數(shù)還有：

list-max-ziplist-entries 512

說明：list數(shù)據(jù)類型多少節(jié)點以下會采用去指針的緊湊存儲格式。

?

list-max-ziplist-value 64

說明：list數(shù)據(jù)類型節(jié)點值大小系哦啊與多少字節(jié)會采用緊湊存儲格式。

set-max-inset-entries 512

說明set數(shù)據(jù)類型內(nèi)部數(shù)據(jù)如果全部是數(shù)值型，且包含多少字節(jié)點以下，會采用緊湊存儲格式。

?

redis內(nèi)部實現(xiàn)沒有對內(nèi)存分配方面做過多的優(yōu)化，一定程度上回存在內(nèi)存碎片，不過大多數(shù)的情況下，這個不會成為redis的性能瓶頸。不過如果在redis內(nèi)部存儲的大部分是數(shù)值型的話，redis內(nèi)部采用了一個shared integer的方式來省去分配內(nèi)存的開銷，即在系統(tǒng)啟動是先分配一個從1~n那么多個數(shù)值對象放在一個池子中，如果存儲的數(shù)據(jù)恰好是這個數(shù)值范圍內(nèi)的數(shù)據(jù)，則直接誒從池子里取出對象。并且通過引用技術(shù)的方式來分享。這樣在系統(tǒng)存儲了大量數(shù)值下，也能在一定程度上節(jié)省內(nèi)存并且提高ixngneng，這個參數(shù)值n的設(shè)置需要修改源代碼中的一行宏定義：REDIS_SHARED_INTERGERS，該值默認(rèn)為10000，可以根據(jù)自己的需要進行修改，修改后重新編譯就可以了。

?

?

redis的持久化機制:

?

四種持久化方式：

定時快照方式---snapshot----------定時器事件---固定時間點檢查當(dāng)前數(shù)據(jù)發(fā)生的改變次數(shù)與時間是否滿足觸發(fā)持久化的條件。滿 足時，就通過fork調(diào)用來創(chuàng)建一個子進程。

這個子進程默認(rèn)會與父進程共享相同的地址空間，這時就可以通過子進程來遍歷整個內(nèi)存來進行存儲操作，而主進程則仍然可 以提供服務(wù)，當(dāng)有寫入時由操作系統(tǒng)按照內(nèi)存頁(page)為單位來進行copy-on-write保證父子進程之間不會互相影響。

基于語句追加文件的方式------aof-------類似mysql基于語句的binlog方式，即每條會使redis內(nèi)存數(shù)據(jù)發(fā)生改變的命令都會追加到 一個log文件中，也就是說這個log文件就是redis的持久化數(shù)據(jù)。

缺點是：追加log文件可能導(dǎo)致體積過大，當(dāng)系統(tǒng)重啟恢復(fù)數(shù)據(jù)時如果是aof的方式則加載數(shù)據(jù)會非常緩慢

虛擬內(nèi)存----vm--------已被遺棄。。。。

Diskstore方式-------B-tree

?

?

設(shè)計思路上，前兩種基于全部數(shù)據(jù)都在內(nèi)存中，即小數(shù)據(jù)量下提供磁盤落地功能。

? ? 后兩種方式則是作者在嘗試存儲數(shù)據(jù)超過物理內(nèi)存時，即大數(shù)據(jù)量的數(shù)據(jù)存儲。仍在實驗階段

?

?

?

redis持久化磁盤IO方式及其帶來的問題。

?

?

redis 崩潰的一個原因：

redis的持久化使用了buffer IO造成的，所謂buffer IO指redis對持久化文件的寫入和讀取操作都會使用物理內(nèi)存page cache 而大多數(shù)數(shù)據(jù)庫系統(tǒng)會使用direct IO來繞過這層page cache 并自行維護一個數(shù)據(jù)cache，。而當(dāng)redis的持久化文件過大,尤其是快照文件。并對其讀寫時，磁盤文件中數(shù)據(jù)都會被加載到物理內(nèi)存中作為操作系統(tǒng)對該文件的一層的cache。而這層cache的數(shù)據(jù)與redis內(nèi)存中管理的數(shù)據(jù)實際是重復(fù)存儲的，雖然內(nèi)核在物理內(nèi)存緊張時會做page cache 的剔除工作， ?但內(nèi)核很可能會認(rèn)為某個page cache 會更重要，而讓你的進程開始swap，這時你的系統(tǒng)就會開始出現(xiàn)不穩(wěn)定或者崩潰了。

補充： page cache，又稱pcache，其中文名稱為 頁高速緩沖存儲器 ，簡稱頁高緩 。page cache的大小為一頁，通常為4K。在linux讀 寫文件時，它用于緩存文件的邏輯內(nèi)容，從而加快對磁盤上映像和數(shù)據(jù)的訪問。

經(jīng)驗：當(dāng)你的redis物理內(nèi)存使用超過內(nèi)存總?cè)萘康?/5，就會開始比較危險了

?

?

?

總結(jié)：

1、根據(jù)業(yè)務(wù)需要選擇核實的數(shù)據(jù)類型，并為不同的應(yīng)用場景設(shè)置相應(yīng)的緊湊存儲參數(shù)

?

2、當(dāng)業(yè)務(wù)場景不需要數(shù)據(jù)持久化時，關(guān)閉所有的持久化方式可以獲得最佳的性能以及做大的內(nèi)存使用量。

?

3、如果需要持久化，根據(jù)是否可以容忍重啟丟失部分?jǐn)?shù)據(jù)在快照方式與語句追加方式之間選擇其一，不要使用虛擬內(nèi)存以及diskstore方式

?

4、不要讓你的redis所在機器物理內(nèi)存使用超過實際內(nèi)存總量的3/5。。