一、特殊編碼：

    自從Redis 2.2之后，很多數據類型都可以通過特殊編碼的方式來進行存儲空間的優化。其中，Hash、List和由Integer組成的Sets都可以通過該方式來優化存儲結構，以便占用更少的空間，在有些情況下，可以省去9/10的空間。
    這些特殊編碼對于Redis的使用而言是完全透明的，事實上，它只是CPU和內存之間的一個交易而言。如果內存使用率方面高一些，那么在操作數據時消耗的CPU自然要多一些，反之亦然。在Redis中提供了一組配置參數用于設置與特殊編碼相關的各種閾值，如：
 

    從Redis 2.2開始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四個用于字符串類型Key/Value的命令。通過這些命令，我們便可以像操作數組那樣來訪問String類型的值數據了。比如唯一標識用戶身份的ID，可能僅僅是String值的其中一段子字符串。這樣就可以通過GETRANGE/SETRANGE命令來方便的提取。再有就是可以使用BITMAP來表示用戶的性別信息，如1表示male，0表示female。用這種方式來表示100,000,000個用戶的性別信息時，也僅僅占用12MB的存儲空間，與此同時，在通過SETBIT/GETBIT命令進行數據遍歷也是非常高效的。
   
三、盡可能使用Hash：

    由于小的Hash類型數據占用的空間相對較少，因此我們在實際應用時應該盡可能的考慮使用Hash類型，比如用戶的注冊信息，這其中包括姓名、性別、email、年齡和口令等字段。我們當然可以將這些信息以Key的形式進行存儲，而用戶填寫的信息則以String Value的形式存儲。然而Redis則更為推薦以Hash的形式存儲，以上信息則以Field/Value的形式表示。
    現在我們就通過學習Redis的存儲機制來進一步證明這一說法。在該篇博客的開始處已經提到了特殊編碼機制，其中有兩個和Hash類型相關的配置參數：hash-max-zipmap-entries和hash-max-zipmap-value。至于它們的作用范圍前面已經給出，這里就不再過多的贅述了。現在我們先假設存儲在Hash Value中的字段數量小于hash-max-zipmap-entries，而每個元素的長度又同時小于hash-max-zipmap-value。這樣每當有新的Hash類型的Key/Value存儲時，Redis都會為Hash Value創建定長的空間，最大可預分配的字節數為:
    total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value
    這樣一來，Hash中所有字段的位置已經預留，并且可以像訪問數組那樣隨機的訪問Field/Value，他們之間的步長間隔為hash-max-zipmap-value。只有當Hash Value中的字段數量或某一新元素的長度分別超過以上兩個參數值時，Redis才會考慮將他們以Hash Table的方式進行重新存儲，否則將始終保持這種高效的存儲和訪問方式。不僅如此，由于每個Key都要存儲一些關聯的系統信息，如過期時間、LRU等，因此和String類型的Key/Value相比，Hash類型極大的減少了Key的數量(大部分的Key都以Hash字段的形式表示并存儲了)，從而進一步優化了存儲空間的使用效率。