Redis本身內容繁雜，要是上來就研究一細節點，如連接池、數據結構，雖可直接學到某個點的詳盡源碼內容，甚至儘快解決一些事故，但容易溺死在細節汪洋，無法整體把控Redis。
最好是先建立起“架構”。想精通Redis，須能領略其總體架構，再深入具體技術點。
構造Redis 這種 KV DB，首要考慮：
數據模型
能存什麼數據？如用戶信息（用戶ID、name、age、sex等），通常用 MySQL，在一個用戶ID對應一個用戶信息集合的場景下，就是KV DB的數據模型之一，也能滿足這類存儲需求。操作接口
可以怎麼操作數據？如計算多個用戶的avg年齡，KV DB則無法勝任。因其只提供了簡單的操作接口，並不支持複雜聚合計算。
所以，先搞懂數據模型和操作接口，才能物盡其用。
數據模型
KV DB，最基本數據模型就是KV模型。選型KV DB時，一大因素就是其支持的V類型：
Memcached僅支持String V類型
而Redis支持的V類型還包括hash、list、set等
所以Redis能被更廣泛應用。
對 crud boy來說，不同V類型就意味着能支持多種業務的數據需求。
===
操作接口
無論什麼DB，基本操作都逃不開 crud：
PUT：新寫入或更新一個KV對
GET：根據一個key讀取相應的V值
DELETE：根據一個key刪除整個KV對
SCAN操作：根據一段K範圍，返回相應V值
內存 or 外存？
在內存，讀寫快，百ns級。風險是一旦掉電，會丟失所有數據
在外存，雖可避免數據丟失，但受限於磁盤慢速讀寫（幾ms級別），KV DB整體性能會被拉低。
因此，需根據KV DB應用場景來選型。
如緩存場景下的數據需要能快速訪問但允許丟失，則採用內存保存KV數據。
訪問模式選型
-
通過函數庫調用供外部使用
如libsimplekv.so，就是以動態鏈接庫的形式鏈接到我們自己的程序，提供KV存儲功能，如RocksDB。
通過網絡框架，以Socket通信對外提供KV對操作，可提供廣泛的KV存儲服務
如Memcached和Redis。
通過網絡框架提供KV存儲服務：
擴大了KV DB的生態
給KV DB的性能、運行模型提供了不同選型，帶來潛在問題
比如，當客戶端發送如下命令，該命令會被封裝在網絡包中發送給KV DB：
PUT java edge
KV DB網絡框架接收到網絡包，並按照相應的協議進行解析後，可知客戶端想寫入一個鍵值對，並開始實際寫入。
I/O模型設計
網絡連接的處理、解析客戶端的請求及數據存取的處理，應該選擇怎樣的線程模型？
一個線程，既要處理網絡連接、解析請求，又要完成數據存取，一旦某一步操作發生阻塞，整個線程就會阻塞住，這就降低了系統響應速度
多線程處理不同操作，則某個線程被阻塞時，其他線程還能正常運行。但不同線程間如果需要訪問共享資源，又會產生線程競爭，影響系統效率
所以，這裏也還需精心設計。
KV對的定位
知道了要進行的KV對操作，就得查找所要操作的KV對是否存在，這就依賴KV DB的索引模塊：讓KV DB據key找到相應V的存儲位置。
不同KV DB採用的索引：
Memcached、Redis採用哈希表
RocksDB採用跳錶
一般內存KV DB（如Redis）採用哈希表作爲索引，主要因其KV基本都保存在內存，而內存高性能隨機訪問特性與哈希表O(1)複雜度匹配。
Redis的V支持多種類型，當通過索引找到一個K所對應V，仍需從V的複雜結構（如set或list）中進一步找到想要數據，該操作的效率本身就依賴其實現結構。而Redis便採用一些高效的索引結構作爲某些V類型的底層數據結構。
各操作的具體邏輯
不同操作找到V的存儲位置後的操作：
GET/SCAN
根據V的存儲位置返回V值PUT
爲該KV對分配內存空間DELETE
刪除KV對，並釋放內存空間，該過程由分配器完成
重啓後快速提供服務
KV DB的KV對大小不一，分配器在處理隨機的大小內存塊分配時，表現不好的話，一旦KV對數據規模過大，可能導致嚴重內存碎片。
所以分配器是KV DB中的關鍵。對內存存儲爲主的Redis更重要。Redis的內存分配器提供了多種選擇，分配效率也不同。
KV DB雖依賴內存保存數據，提供快速訪問，但也希望KV DB重啓後能快速重新提供服務，所以，在其存儲模塊增加持久化功能。
因爲磁盤管理比內存管理複雜，KV DB直接採用文件形式，將KV數據通過調用本地文件系統的操作接口保存在磁盤。
此時，KV DB只需考慮何時將內存中的KV數據保存到文件：
每個KV對都落盤保存，這雖然讓數據更可靠，但每次都寫盤，性能受大影響
週期性把內存中的KV對保存到文件，避免頻繁寫盤。但數據有丟失風險
所以，Redis提供了持久化功能，還有多種執行機制和性能優化點。
KV DB - Redis 架構
