redis由哪幾個模塊組成欺冀，每個模塊有什么用
訪問框架：動態(tài)鏈接庫侈离、網(wǎng)絡(luò)訪問框架
操作模塊：PUT试幽、DELETE、GET、SCAN【基本操作】铺坞，redis還有其他特殊操作對應(yīng)不同的數(shù)據(jù)類型
索引模塊：查詢數(shù)據(jù)
存儲模塊：基于內(nèi)存起宽，同時提供持久化數(shù)據(jù)功能
redis支持什么樣的格式存儲，每種數(shù)據(jù)支持哪些操作
- key僅支持String
- 對于value支持以下集中類型：
字符串:String
哈希表:Hash
集合:Set
排序集合:sorted Set
壓縮列表: Compressed Set -
底層數(shù)據(jù)結(jié)構(gòu)一共有 6 種济榨，分別是簡單動態(tài)字符串坯沪、雙向鏈表、壓縮列表擒滑、哈希表腐晾、跳表和整數(shù)數(shù)組
image.png - redis的key-value使用全局哈希表進(jìn)行存儲，其實就是一個數(shù)組丐一，數(shù)組的每個元素稱為一個哈希桶
??哈希桶中的 entry 元素中保存了key和value指針藻糖，分別指向了實際的鍵和值，這樣一來库车，即使值是一個集合巨柒，也可以通過*value指針被查找到
image.png -
哈希沖突如何解決
??使用鏈?zhǔn)教幚矸ǎ霈F(xiàn)沖突時使用指針鏈接到同一個桶的鏈表后面柠衍，如圖所示
image.png - rehash是什么以及如何解決大數(shù)據(jù)情境下rehash導(dǎo)致慢的問題
rehash：rehash 也就是增加現(xiàn)有的哈希桶數(shù)量洋满，讓逐漸增多的 entry 元素能在更多的桶之間分散保存，減少單個桶中的元素數(shù)量珍坊，從而減少單個桶中的沖突牺勾；
??為了使 rehash 操作更高效，Redis 默認(rèn)使用了兩個全局哈希表：哈希表 1 和哈希表 2阵漏。一開始驻民，當(dāng)你剛插入數(shù)據(jù)時，默認(rèn)使用哈希表 1袱饭，此時的哈希表 2 并沒有被分配空間川无，隨著數(shù)據(jù)逐步增多，Redis 開始執(zhí)行 rehash虑乖，這個過程分為三步：
1懦趋、給哈希表 2 分配更大的空間，例如是當(dāng)前哈希表 1 大小的兩倍疹味；
2仅叫、把哈希表 1 中的數(shù)據(jù)重新映射并拷貝到哈希表 2 中；
3糙捺、釋放哈希表 1 的空間诫咱。 -
Redis 采用了漸進(jìn)式 rehash，解決大數(shù)據(jù)情況下rehash導(dǎo)致慢的問題
??Redis 仍然正常處理客戶端請求洪灯，每處理一個請求時坎缭，從哈希表 1 中的第一個索引位置開始，順帶著將這個索引位置上的所有 entries 拷貝到哈希表 2 中；等處理下一個請求時掏呼，再順帶拷貝哈希表 1 中的下一個索引位置的 entries坏快。如下圖所示：
image.png -
壓縮列表
??壓縮列表實際上類似于一個數(shù)組，數(shù)組中的每一個元素都對應(yīng)保存一個數(shù)據(jù)憎夷。和數(shù)組不同的是莽鸿，壓縮列表在表頭有三個字段 zlbytes、zltail 和 zllen拾给，分別表示列表長度祥得、列表尾的偏移量和列表中的 entry 個數(shù)；壓縮列表在表尾還有一個 zlend蒋得，表示列表結(jié)束：
image.png -
跳表
??有序鏈表只能逐一查找元素级及，導(dǎo)致操作起來非常緩慢，于是就出現(xiàn)了跳表额衙。具體來說创千，跳表在鏈表的基礎(chǔ)上，增加了多級索引入偷，通過索引位置的幾個跳轉(zhuǎn)，實現(xiàn)數(shù)據(jù)的快速定位械哟，如下圖所示：
image.png -
不同底層數(shù)據(jù)結(jié)構(gòu)的時間復(fù)雜度
image.png
-不同操作的復(fù)雜度
單元素操作是基礎(chǔ)疏之；范圍操作非常耗時；統(tǒng)計操作通常高效暇咆；例外情況只有幾個锋爪。
redis的應(yīng)用場景，可以解決哪些問題
- 緩存問題
- 秒殺
- 分布式鎖
參考資料
https://www.cnblogs.com/ysocean/p/9080942.html
https://time.geekbang.org/column/article/268253
