入門到精通，理論到實戰！這份Redis寶典真不愧為“史詩鉅作”

由 Java全棧攻城獅發表于網路遊戲
2023-01-05

簡介編碼和底層實現字串物件雜湊物件第二部分、單機資料庫的實現第9章資料庫第10章RDB持久化第11章AOF持久化第12章事件第13章客戶端第14章伺服器RDB檔案結構在本章之前的內容中，我們介紹了Redis伺服器儲存和載入RDB檔案的方法，在

怎麼把redis用精通

前言

Redis如今已經成為Web開發社群中最火熱的記憶體資料庫之一，而它的誕生距現在不過才4年。隨著Web 2。0的蓬勃發展，網站資料快速增長，對高效能讀寫的需求也越來越多，再加上半結構化的資料比重逐漸變大，人們對早已被鋪天蓋地地運用著的關係資料庫能否適應現今的儲存需求產生了疑問。而Redis的迅猛發展，為這個領域注入了全新的思維。

Redis憑藉其全面的功能得到越來越多的公司的青睞，從初創企業到新浪微博這樣擁有著幾百臺Redis伺服器的大公司，都能看到Redis的身影。Redis也是一個名副其實的多面手，無論是儲存、佇列還是快取系統，都有它的用武之地。

它扮演著多樣的角色，發揮了重要的作用。架構師的職責之一就是技術選型，瞭解redis的原理、特點、優勢和不足，是成為架構師必不可少的一環。

第一份筆記：Redis核心原理和應用實踐

應用篇

延時佇列

HyperLogLog

簡單限流

GeoHash

Scan

分散式鎖

分散式應用進行邏輯處理時經常會遇到併發問題。

比如一個操作要修改使用者的狀態，修改狀態需要先讀出使用者的狀態，在記憶體裡進行修改，改完了再存回去。如果這樣的操作同時進行了，就會出現併發問題，因為讀取和儲存狀態這兩個操作不是原子的。（Wiki 解釋：所謂原子操作是指不會被執行緒排程機制打斷的操作；這種操作一旦開始，就一直執行到結束，中間不會有任何context switch執行緒切換。）

分散式鎖本質上要實現的目標就是在Redis裡面佔一個“茅坑”，當別的程序也要來佔時，發現已經有人蹲在那裡了，就只好放棄或者稍後再試。

點陣圖

點陣圖不是特殊的資料結構，它的內容其實就是普通的字串，也就是byte 陣列。我們可以使用普通的get/set 直接獲取和設定整個點陣圖的內容，也可以使用點陣圖操作getbit/setbit等將byte 陣列看成「位陣列」來處理。

HyperLogLog實現原理

知識點比較多，程式碼就略過了…………Σ（ ° △ °|||）︴

布隆過濾器

上一節我們學會了使用HyperLogLog 資料結構來進行估數，它非常有價值，可以解決很多精確度不高的統計需求。

但是如果我們想知道某一個值是不是已經在HyperLogLog 結構裡面了，它就無能為力了，它只提供了pfadd 和pfcount 方法，沒有提供pfcontains 這種方法。

漏斗限流

漏斗限流是最常用的限流方法之一，顧名思義，這個演算法的靈感源於漏斗（ funnel）的結構。

原理篇

執行緒IO模型

通訊協議

持久化

管道

事務

PubSub

小物件壓縮

主從同步

事件輪詢(多路複用)

非阻塞IO有個問題，那就是執行緒要讀資料，結果讀了一部分就返回了，執行緒如何知道何時才應該繼續讀。也就是當資料到來時，執行緒如何得到通知。寫也是一樣，如果緩衝區滿了，寫不完，剩下的資料何時才應該繼續寫，執行緒也應該得到通知。

Redis 4.0混合持久化

重啟Redis 時，我們很少使用rdb來恢復記憶體狀態，因為會丟失大量資料。我們通常使用AOF日誌重放，但是重放AOF日誌效能相對rdb 來說要慢很多，這樣在Redis 例項很大的情況下，啟動需要花費很長的時間。

Redis的訊息互動

當我們使用客戶端對Redis 進行一次操作時，如下圖所示，客戶端將請求傳送給伺服器，伺服器處理完畢後，再將響應回覆給客戶端。這要花費一個網路資料包來回的時間。

深入理解管道本質

接下來我們深入分析一個請求互動的流程，真實的情況是它很複雜，因為要經過網路協議棧，這個就得深入核心了。

CAP原理

CAP原理就好比分散式領域的牛頓定律，它是分散式儲存的理論基石。自打CAP的論文發表之後，分散式儲存中介軟體猶如雨後春筍般一個-個湧現出來。理解這個原理其實很簡單，本節我們首先對這個原理進行一些簡單的講解。

C - Consistent，一致性

A- Availability , 可用性

P - Partition tolerance，分割槽容忍性

叢集篇

Sentinel

Codi

Cluster

MGET指令的操作過程

Codis的後臺管理

後臺管理的介面非常友好，使用了最新的BootStrap 前端框架。比較酷炫的是可以看到實時的QPS波動曲線。

同時還支援伺服器叢集管理功能，可以增加分組、增加節點、執行自動均衡等指令，還可以直接檢視所有slot 的狀態，每個slot 被分配到哪個Redis例項。

遷移

Redis Cluster提供了工具redis-trib 可以讓運維人員手動調整槽位的分配情況，它使用Ruby語言進行開發，透過組合各種原生的Redis Cluster指令來實現。這點Codis 做的更加人性化，它不但提供了UI 介面可以讓我們方便的遷移，還提供了自動化平衡槽位工具，無需人工干預就可以均衡叢集負載。不過Redis 官方向來的策略就是提供最小可用的工具，其它都交由社群完成。

拓展篇

Stream

Info指令

再談分散式鎖

過期策略

LRU

懶惰刪除

優雅地使用Jedis

保護Redis

Redis安全通訊

建立消費組

Redis每秒執行多少次指令?

非同步佇列

主執行緒將物件的引用從「大樹」中摘除後，會將這個key的記憶體回收操作包裝成-一個任務，塞進非同步任務佇列，後臺執行緒會從這個非同步佇列中取任務。任務佇列被主執行緒和非同步執行緒同時操作，所以必須是一個執行緒安全的佇列。

spiped原理

讓我們放大細節，仔細觀察spiped 實現原理。spiped 會在客戶端和伺服器各啟動一個spiped程序。

原始碼篇

探索「字串」內部結構

探索［字典」內部

探索「壓縮列表」內部

探索「快速列表」內部

探索「跳躍列表」內部結構

探索「緊湊列表」內部

探索「基數樹」內部

dict內部結構

壓縮深度

基本結構

應用

你可以將一本英語字典看成一棵radix tree，，它所有的單詞都是按照字典序進行排列，每個詞彙都會附帶一個解釋，這個解釋就是key 對應的value。有了這棵樹，你就可以快速地檢索單詞，還可以查詢以某個字首開頭的單詞有哪些。

第二份筆記：Redis設計與實現

目錄大綱

章節過多就不一一詳記了，筆記完整版在文末，可供大家參考

第一部分、資料結構與物件

第2章簡單動態字串

第3章連結串列

第4章字典

第5章跳躍表

第6章整數集合

第7章壓縮列表

第8章物件

SDS與C字串的區別

SDS API

連結串列和連結串列節點的實現

雜湊演算法

當要將一個新的鍵值對新增到字典裡面時，程式需要先根據鍵值對的鍵計算出雜湊值和索引值，然後再根據索引值，將包含新鍵值對的雜湊表節點放到雜湊表陣列的指定索引上面。

跳躍表的實現

Redis的跳躍表由redis。h/zskiplistNode和redis。h/zskiplist兩個結構定義，其中zskiplistNode結構用於表示跳躍表節點，而zskiplist結構則用於儲存跳躍表節點的相關資訊，比如節點的數量，以及指向表頭節點和表尾節點的指標等等。

編碼和底層實現

字串物件

雜湊物件

第二部分、單機資料庫的實現

第9章資料庫

第10章RDB持久化

第11章AOF持久化

第12章事件

第13章客戶端

第14章伺服器

RDB檔案結構

在本章之前的內容中，我們介紹了Redis伺服器儲存和載入RDB檔案的方法，在這一節，我們將對RDB檔案本身進行介紹，並詳細說明檔案各個部分的結構和意義。

AOF持久化

除了RDB持久化功能之外，Redis還提供了AOF （Append OnlyFile）持久化功能。與RDB持久化透過儲存資料庫中的鍵值對來記錄資料庫狀態不同，AOF持久化是透過儲存Redis伺服器所執行的寫命令來記錄資料庫狀態的，如圖11-1所示。

檔案事件處理器的構成

圖12-1展示了檔案事件處理器的四個組成部分，它們分別是套接字、I/O多路複用程式、檔案事件分派器（dispatcher），以及事件處理器。

I/O多路複用程式的實現

Redis的I/O多路複用程式的所有功能都是透過包裝常見的select、epoll、evport 和kqueue這些I/O多路複用函式庫來實現的，每個I/O多路複用函式庫在Redis原始碼中都對應-個單獨的檔案，比如ae_select。c、ae_ epoll。c、ae_ kqueue。c，諸如此類。

第三部分、多機資料庫的實現

第15章複製

第16章Sentinel

第17章叢集

客戶端的建立與關閉

伺服器使用不同的方式來建立和關閉不同型別的客戶端，本節將介紹伺服器建立和關閉客戶端的方法。

傳送命令請求

Redis伺服器的命令請求來自Redis客戶端，當用戶在客戶端中鍵入一個命令請求時，客戶端會將這個命令請求轉換成協議格式，然後透過連線到伺服器的套接字，將協議格式的命令請求傳送給伺服器，如圖14-1所示。

Sentinel簡介

Sentinel （哨崗、哨兵）是Redis的高可用性（high availability）解決方案：由一個或多個Sentinel例項（ instance）組成的Sentinel 系統（system）可以監視任意多個主伺服器，以及這些主伺服器屬下的所有從伺服器，並在被監視的主伺服器進入下線狀態時，自動將下線主伺服器屬下的某個從伺服器升級為新的主伺服器，然後由新的主伺服器代替已下線的主伺服器繼續處理命令請求。