Redis設計思路學習與總結

Redis是業界普遍應用的緩存元件，研究一個元件架構，最直覺的辦法就是從應用方的角度出發，将每個步驟的考慮一番，從這些步驟入手去研究往往能夠最快的體會到一個元件架構的設計哲學。以Redis為例，每當發起一條請求時，redis是如何管理管理網絡請求，收到請求後又是通過什麼樣的資料結構進行組織并操作記憶體，這些資料又是如何dump到磁盤實作持久化，再到多機環境下如何同步和保證一緻性……本文就是從網絡模型、資料結構設計與記憶體管理、持久化方法和多機四個角度簡要描述了redis的設計和自己的一點體會。

下半年利用空餘時間研究和分析了部分Redis源碼，本文從網絡模型、資料結構和記憶體管理、持久化和多機協作四個角度對redis的設計思路進行了分析，若有不正确之處，希望各路大神指出。

Redis是業界普遍應用的緩存元件，研究一個元件架構，最直覺的辦法就是從應用方的角度出發，将每個步驟的考慮一番，從這些步驟入手去研究往往能夠最快的體會到一個元件架構的設計哲學。以Redis為例，每當發起一條請求時，Redis是如何管理管理網絡請求，收到請求後又是通過什麼樣的資料結構進行組織并操作記憶體，這些資料又是如何dump到磁盤實作持久化，再到多機環境下如何同步和保證一緻性……本文就是從網絡模型、資料結構設計與記憶體管理、持久化方法和多機四個角度簡要描述了redis的設計和自己的一點體會。

一.網絡模型

Redis是典型的基于Reactor的事件驅動模型，單程序單線程，高效的架構總是類似的。網絡模型與spp的異步模型幾乎一緻。

Redis流程上整體分為接受請求處理器、響應處理器和應答處理器三個同步子產品，每一個請求都是要經曆這三個部分。

Redis內建了

libevent/epoll/kqueue/select

等多種事件管理機制，可以根據作業系統版本自由選擇合适的管理機制，其中libevent是最優選擇的機制。

Redis的網絡模型有着所有事件驅動模型的優點，高效低耗。但是面對耗時較長的操作的時候，同樣無法處理請求，隻能等到事件處理完畢才能響應，之前在業務中也遇到過這樣的場景，删除redis中全量的key-value，整個操作時間較長，操作期間所有的請求都無法響應。是以了解清楚網絡模型有助于在業務中揚長避短，減少長耗時的請求，盡可能多一些簡單的短耗時請求發揮異步模型的最大的威力，事實上在Redis的設計中也多次展現這一點。

二.資料結構和記憶體管理

1.字元串

1.1 結構

Redis的字元串是對C語言原始字元串的二次封裝，結構如下：

struct sdshdr {
    long len;
    long free;
    char buf[];
};

可以看出，每當定義一個字元串時，除了儲存字元的空間，Redis還配置設定了額外的空間用于管理屬性字段。

1.2 記憶體管理方式

動态記憶體管理方式，動态方式最大的好處就是能夠較為充分的利用記憶體空間，減少記憶體碎片化，與此同時帶來的劣勢就是容易引起頻繁的記憶體抖動，通常采用“空間預配置設定”和“惰性空間釋放”兩種優化政策來減少記憶體抖動，redis也不例外。

每次修改字元串内容時，首先檢查記憶體空間是否符合要求，否則就擴大2倍或者按M增長；減少字元串内容時，記憶體并不會立刻回收，而是按需回收。

關于記憶體管理的優化，最基本的出發點就是浪費一點空間還是犧牲一些時間的權衡，像STL、tcmalloc、protobuf3的arena機制等采用的核心思路都是“預配置設定遲回收”，Redis也是一樣的。

1.3 二進制安全

判斷字元串結束與否的辨別是len字段，而不是C語言的'\0'，是以是二進制安全的。

放心的将pb序列化後的二進制字元串存入redis。

簡而言之，通過redis的簡單封裝，redis的字元串的操作更加友善，性能更友好，并且屏蔽了C語言字元串的一些需要使用者關心的問題。

2.字典（哈希）

字典的底層一定是hash，涉及到hash一定會涉及到hash算法、沖突的解決方法和hash表擴容和縮容。

2.1 hash算法

Redis使用的就是常用的Murmurhash2，Murmurhash算法能夠給出在任意輸入序列下的散列分布性，并且計算速度很快。之前做共享記憶體的Local-Cache的需求時也正是利用了Murmurhash的優勢，解決了原有結構的hash函數散列分布性差的問題。

2.2 hash沖突解決方法

鍊位址法解決hash沖突，通用解決方案沒什麼特殊的。多說一句，如果選用鍊位址解決沖突，那麼勢必要有一個散列性非常好的hash函數，否則hash的性能将會大大折扣。Redis選用了Murmurhash，是以可以放心大膽的采用鍊位址方案。

2.3 hash擴容和縮容

維持hash表在一個合理的負載範圍之内，簡稱為rehash過程。

rehash的過程也是一個權衡的過程，在做評估之前首先明确一點，不管中間采用什麼樣的rehash政策，rehash在宏觀上看一定是：配置設定一個新的記憶體塊，老資料搬到新的記憶體塊上，釋放舊記憶體塊。

老資料何時搬？怎麼搬？就變成了一個需要權衡的問題。

第一部分的網絡模型上明确的指出Redis的事件驅動模型特點，不适合玩長耗時操作。如果一個hashtable非常大，需要進行擴容就一次性把老資料copy過去，那就會非常耗時，違背事件驅動的特點。是以Redis依舊采用了一種惰性的方案：

新空間配置設定完畢後，啟動rehashidx辨別符表明rehash過程的開始；之後所有增删改查涉及的操作時都會将資料遷移到新空間，直到老空間資料大小為0表明資料已經全部在新空間，将rehashidx禁用，表明rehash結束。

将一次性的集中問題分而治之，在Redis的設計哲學中展現的淋漓盡緻，主要是為了避免大耗時操作，影響Redis響應客戶請求。

3.整數集合

變長整數存儲，整數分為16/32/64三個變長尺度，根據存入的資料所屬的類型，進行規劃。

每次插入新元素都有可能導緻尺度更新（例如由16位漲到32位），是以插入整數的時間複雜度為O（n）。這裡也是一個權衡，記憶體空間和時間的一個折中，盡可能節省記憶體。

4.跳躍表

Redis的skilplist和普通的skiplist沒什麼不同，都是備援資料實作的從粗到細的多層次連結清單，Redis中應用跳表的地方不多，常見的就是有序集合。

Redis的跳表和普通skiplist沒有什麼特殊之處。

5.連結清單

Redis的連結清單是雙向非循環連結清單，擁有表頭和表尾指針，對于首尾的操作時間複雜度是O(1)，查找時間複雜度O(n)，插入時間複雜度O(1)。

Redis的連結清單和普通連結清單沒有什麼特殊之處。

三.AOF和RDB持久化

AOF持久化日志，RDB持久化實體資料，AOF優先級大于RDB。

1.AOF持久化

機制：通過定時事件将aof緩沖區内的資料定時寫到磁盤上。

2.AOF重寫

為了減少AOF大小，Redis提供了AOF重寫功能，這個重寫功能做的工作就是建立一個新AOF檔案代替老的AOF，并且這個新的AOF檔案沒有一條備援指令。（例如對list先插入A/B/C，後删除B/C，再插入D共6條指令，最終狀态為A/D，隻需1條指令就可以）

實作原理就是讀現有資料庫的狀态，根據狀态反推指令，跟之前的AOF無關。同樣，為了避免長時間耗時，重寫工作放在子程序進行。

3.RDB持久化

SAVE和BGSAVE兩個指令都是用于生成RDB檔案，差別在于BGSAVE會fork出一個子程序單獨進行，不影響Redis處理正常請求。

定時和定次數後進行持久化操作。

簡而言之，RDB的過程其實是比較簡單的，滿足條件後直接去寫RDB檔案就結束了。

四.多機和叢集

1.主從伺服器

避免單點是所有服務的通用問題，Redis也不例外。解決單點就要有備機，有備機就要解決固有的資料同步問題。

1.1 sync——原始版主從同步

Redis最初的同步做法是sync指令，通過sync每次都會全量資料，顯然每次都全量複制的設計比較消耗資源。改進思路也是正常邏輯，第一次全量，剩下的增量，這就是現在的psync指令的活。

1.2 psync

部分重同步實作的技術手段是“偏移序号+積壓緩沖區”，具體做法如下：

（1）主從分别維護一個seq，主每次完成一個請求便seq+1，從每同步完後更新自己seq；

（2）從每次打算同步時都是攜帶着自己的seq到主，主将自身的seq與從做差結果與積壓緩沖區大小比較，如果小于積壓緩沖區大小，直接從積壓緩沖區取相應的操作進行部分重同步；

（3）否則說明積壓緩沖區不能夠cover掉主從不一緻的資料，進行全量同步。

本質做法用空間換時間，顯然在這裡犧牲部分空間換回高效的部分重同步，收益比很大。

2.Sentinel

本質：多主從伺服器的Redis系統，多台主從上加了管理監控，以保證系統高可用性。

3.叢集

Redis的官方版叢集尚未在工業界普及起來，下面主要介紹一下叢集的管理體系和運轉體系。

2.1 slot-叢集機關

叢集的資料區由slot組成，每個節點負責的slot是在叢集啟動時配置設定的。

2.2 客戶請求

客戶請求時如果相應資料hash後不屬于請求節點所管理的slots，會給客戶傳回MOVED錯誤，并給出正确的slots。

從這個層面看，redis的叢集還不夠友好，叢集内部的狀态必須由客戶感覺。

2.3 容災

主從伺服器，從用于備份主，一旦主故障，從代替主。

通過Redis的研究，深刻體會到的一點就是：所有設計的過程都是權衡和割舍的過程。同樣放到日常的工作和開發中也是如此，一句代碼寫的好不好，一個子產品設計的是否科學，就從速度和記憶體的角度去衡量看是否需要優化，并去評估每一種優化會收益到什麼，同時會損失什麼，收益遠大于損失的就是好的優化，這樣往往對于開發和提升更有針對性，更能提高效率。