本文從網絡模型、數據結構和內存管理、持久化和多機協做四個角度對redis的設計思路進行分析。
一.網絡模型redis
Redis是典型的基於Reactor的事件驅動模型,單進程單線程,高效的框架老是相似的。網絡模型與spp的異步模型幾乎一致。算法
Redis流程上總體分爲接受請求處理器、響應處理器和應答處理器三個同步模塊,每個請求都是要經歷這三個部分。數據庫
Redis集成了libevent/epoll/kqueue/select等多種事件管理機制,能夠根據操做系統版本自由選擇合適的管理機制,其中libevent是最優選擇的機制。安全
Redis的網絡模型有着全部事件驅動模型的優勢,高效低耗。可是面對耗時較長的操做的時候,一樣沒法處理請求,只能等到事件處理完畢才能響應。因此瞭解清楚網絡模型有助於在業務中揚長避短,減小長耗時的請求,儘量多一些簡單的短耗時請求發揮異步模型的最大的威力。服務器
二.數據結構和內存管理網絡
1.字符串數據結構
1.1 內存管理方式框架
動態內存管理方式,動態方式最大的好處就是可以較爲充分的利用內存空間,減小內存碎片化,與此同時帶來的劣勢就是容易引發頻繁的內存抖動,一般採用「空間預分配」和「惰性空間釋放」兩種優化策略來減小內存抖動,redis也不例外。異步
每次修改字符串內容時,首先檢查內存空間是否符合要求,不然就擴大2倍或者按M增加;減小字符串內容時,內存並不會馬上回收,而是按需回收。ide
關於內存管理的優化,最基本的出發點就是浪費一點空間仍是犧牲一些時間的權衡,像STL、tcmalloc、protobuf3的arena機制等採用的核心思路都是「預分配遲迴收」,Redis也是同樣的。
1.2 二進制安全
判斷字符串結束與否的標識是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,因此能夠放心大膽的採用鏈地址方案。
3.整數集合
變長整數存儲,整數分爲16/32/64三個變長尺度,根據存入的數據所屬的類型,進行規劃。
每次插入新元素都有可能致使尺度升級(例如由16位漲到32位),所以插入整數的時間複雜度爲O(n)。這裏也是一個權衡,內存空間和時間的一個折中,儘量節省內存。
4.跳躍表
Redis的skilplist和普通的skiplist沒什麼不一樣,都是冗餘數據實現的從粗到細的多層次鏈表,Redis中應用跳錶的地方很少,常見的就是有序集合。
5.鏈表
Redis的鏈表是雙向非循環鏈表,擁有表頭和表尾指針,對於首尾的操做時間複雜度是O(1),查找時間複雜度O(n),插入時間複雜度O(1)。
三.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系統,多臺主從上加了管理監控,以保證系統高可用性。