實(shí)現(xiàn)方式：
上面已經(jīng)說到 Redis Hash 對(duì)應(yīng) Value 內(nèi)部實(shí)際就是一個(gè) HashMap，實(shí)際這里會(huì)有2種不同實(shí)現(xiàn)，這個(gè) Hash 的成員比較少時(shí) Redis 為了節(jié)省內(nèi)存會(huì)采用類似一維數(shù)組的方式來緊湊存儲(chǔ)，而不會(huì)采用真正的 HashMap 結(jié)構(gòu)，對(duì)應(yīng)的 value redisObject 的 encoding 為 zipmap，當(dāng)成員數(shù)量增大時(shí)會(huì)自動(dòng)轉(zhuǎn)成真正的 HashMap，此時(shí) 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)來實(shí)現(xiàn)，比較好理解，這里不再重復(fù)。
實(shí)現(xiàn)方式：
Redis list 的實(shí)現(xiàn)為一個(gè)雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內(nèi)存開銷，Redis 內(nèi)部的很多實(shí)現(xiàn)，包括發(fā)送緩沖隊(duì)列等也都是用的這個(gè)數(shù)據(jù)結(jié)構(gòu)。
Set
常用命令：
sadd,spop,smembers,sunion 等。
應(yīng)用場景：
Redis set 對(duì)外提供的功能與 list 類似是一個(gè)列表的功能，特殊之處在于 set 是可以自動(dòng)排重的，當(dāng)你需要存儲(chǔ)一個(gè)列表數(shù)據(jù)，又不希望出現(xiàn)重復(fù)數(shù)據(jù)時(shí)，set 是一個(gè)很好的選擇，并且 set 提供了判斷某個(gè)成員是否在一個(gè) set 集合內(nèi)的重要接口，這個(gè)也是 list 所不能提供的。
實(shí)現(xiàn)方式：
set 的內(nèi)部實(shí)現(xiàn)是一個(gè) value 永遠(yuǎn)為 null 的 HashMap，實(shí)際就是通過計(jì)算 hash 的方式來快速排重的，這也是 set 能提供判斷一個(gè)成員是否在集合內(nèi)的原因。
Sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用場景：
Redis sorted set 的使用場景與 set 類似，區(qū)別是 set 不是自動(dòng)有序的，而 sorted set 可以通過用戶額外提供一個(gè)優(yōu)先級(jí)(score)的參數(shù)來為成員排序，并且是插入有序的，即自動(dòng)排序。當(dāng)你需要一個(gè)有序的并且不重復(fù)的集合列表，那么可以選擇 sorted set 數(shù)據(jù)結(jié)構(gòu)，比如 twitter 的 public timeline 可以以發(fā)表時(shí)間作為 score 來存儲(chǔ)，這樣獲取時(shí)就是自動(dòng)按時(shí)間排好序的。
實(shí)現(xiàn)方式：
Redis sorted set 的內(nèi)部使用 HashMap 和跳躍表(SkipList)來保證數(shù)據(jù)的存儲(chǔ)和有序，HashMap 里放的是成員到 score 的映射，而跳躍表里存放的是所有的成員，排序依據(jù)是 HashMap 里存的 score，使用跳躍表的結(jié)構(gòu)可以獲得比較高的查找效率，并且在實(shí)現(xiàn)上比較簡單。
常用內(nèi)存優(yōu)化手段與參數(shù)
通過我們上面的一些實(shí)現(xiàn)上的分析可以看出 redis 實(shí)際上的內(nèi)存管理成本非常高，即占用了過多的內(nèi)存，作者對(duì)這點(diǎn)也非常清楚，所以提供了一系列的參數(shù)和手段來控制和節(jié)省內(nèi)存，我們分別來討論下。
首先最重要的一點(diǎn)是不要開啟 Redis 的 VM 選項(xiàng)，即虛擬內(nèi)存功能，這個(gè)本來是作為 Redis 存儲(chǔ)超出物理內(nèi)存數(shù)據(jù)的一種數(shù)據(jù)在內(nèi)存與磁盤換入換出的一個(gè)持久化策略，但是其內(nèi)存管理成本也非常的高，并且我們后續(xù)會(huì)分析此種持久化策略并不成熟，所以要關(guān)閉 VM 功能，請(qǐng)檢查你的 redis.conf 文件中 vm-enabled 為 no。
其次最好設(shè)置下 redis.conf 中的 maxmemory 選項(xiàng)，該選項(xiàng)是告訴 Redis 當(dāng)使用了多少物理內(nèi)存后就開始拒絕后續(xù)的寫入請(qǐng)求，該參數(shù)能很好的保護(hù)好你的 Redis 不會(huì)因?yàn)槭褂昧诉^多的物理內(nèi)存而導(dǎo)致 swap，最終嚴(yán)重影響性能甚至崩潰。
另外 Redis 為不同數(shù)據(jù)類型分別提供了一組參數(shù)來控制內(nèi)存使用，我們?cè)谇懊嬖敿?xì)分析過 Redis Hash 是 value 內(nèi)部為一個(gè) HashMap，如果該 Map 的成員數(shù)比較少，則會(huì)采用類似一維線性的緊湊格式來存儲(chǔ)該 Map，即省去了大量指針的內(nèi)存開銷，這個(gè)參數(shù)控制對(duì)應(yīng)在 redis.conf 配置文件中下面2項(xiàng)：
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
hash-max-zipmap-entries
含義是當(dāng) value 這個(gè) Map 內(nèi)部不超過多少個(gè)成員時(shí)會(huì)采用線性緊湊格式存儲(chǔ)，默認(rèn)是64，即 value 內(nèi)部有64個(gè)以下的成員就是使用線性緊湊存儲(chǔ)，超過該值自動(dòng)轉(zhuǎn)成真正的 HashMap。
hash-max-zipmap-value 含義是當(dāng) value 這個(gè) Map 內(nèi)部的每個(gè)成員值長度不超過多少字節(jié)就會(huì)采用線性緊湊存儲(chǔ)來節(jié)省空間。
以上2個(gè)條件任意一個(gè)條件超過設(shè)置值都會(huì)轉(zhuǎn)換成真正的 HashMap，也就不會(huì)再節(jié)省內(nèi)存了，那么這個(gè)值是不是設(shè)置的越大越好呢，答案當(dāng)然是否定的，HashMap 的優(yōu)勢就是查找和操作的時(shí)間復(fù)雜度都是 O(1) 的，而放棄 Hash 采用一維存儲(chǔ)則是 O(n) 的時(shí)間復(fù)雜度，如果成員數(shù)量很少，則影響不大，否則會(huì)嚴(yán)重影響性能，所以要權(quán)衡好這個(gè)值的設(shè)置，總體上還是最根本的時(shí)間成本和空間成本上的權(quán)衡。