一、Redis 基礎數據結構

1. String

Redis 里的字符串是動態字符串，會根據實際情況動態調整。類似于 Go 里面的切片-slice，如果長度不夠則自動擴容。至于如何擴容，方法大致如下：當 length 小于 1M 的時候，擴容規則將目前的字符串翻倍；如果 length 大于 1M 的話，則每次只會擴容 1M，直到達到 512M。

2. List

Redis 里的 List 是一個鏈表，由于鏈表本身插入和刪除比較塊，但是查詢的效率比較低，所以常常被用做異步隊列。Redis 里的 List 設計非常牛，當數據量比較小的時候，數據結構是壓縮鏈表，而當數據量比較多的時候就成為了快速鏈表。 可運用的場景：在業務中異步隊列使用 rpush/lpush 操作隊列，使用 lpop 和 rpop 出隊列，具體結構如下圖所示：

3. Set Redis 中的 set 是一個無序 Map，由于 Go 中沒有 set 結構，所以這里只能類比 Java 中的 HashSet 概念。Redis 的 set 底層也是一個 Map 結構，不同于 Java 的是：alue 是一個 NULL。由于 set 的特性，它可以用于去重邏輯，這一點在 Java 中也經常使用。 可運用場景：活動抽獎去重。

4. Hash Redis 中的字典類型大家不陌生，也許其他語言都有這種結構（python，Java，Go）， hash 的擴容 rehash 過程和 Go 里面的設計頗有類似，也就是維護了兩個 hash 結構，如果需要擴容的時候，就把新的數據寫入新字典中，然后后端起一個線程來逐步遷移，總體上來說就是采用了空間換時間的思想。 可運用場景：記錄業務中的不同用戶/不同商品/不同場景的信息：如某個用戶的名稱，或者用戶的歷史行為。

5. Zset

Redis 中的 zset 是一個比較特殊的數據結構（跳躍列表），也就是我們了解到的跳表，底層由于 set 的特性保證了 value 唯一，同時也給了 value 一個得分，所謂的有序其實就是根據這個得分來排序。至于跳躍表如何插入，其實內部采用了一個隨機策略：L0:100%-L2:50%-L3:25%-。。。.Ln：（n-1）value/2%。 可運用場景：榜單，總榜，熱榜。

二、Redis 進階使用

1. 布隆過濾器

Redis 在 4.0 以后支持布隆過濾（準確的來說是支持了布隆過濾器的插件），給 Redis 提供了強大的去重功能。在業務中，我們可能需要查詢數據庫判斷歷史數據是否存在，如果數據庫的并發能力有限，這個時候我們可以采用 Redis 的 set 做去重。

如果緩存的數據過大，這個時候就需要遍歷所有緩存數據，另外如果我們的歷史數據緩存寫不下了，終究要去查詢數據庫，這個時候就可以使用布隆過濾器。 當然布隆過濾器精確度不是 100% 準確（如果對數據準確度要求很高的話，這里不建議使用），因為對于存在的數據也許這個值不一定存在，當然如果不存在，那肯定 100% 不存在了。

（1）命令使用

bf.add #添加元素bf.exists #判斷元素是否存在bf.madd #批量添加bf.mexists #批量判斷是否存在

（2）原理

布隆過濾的組成可以當作一個位數組和幾個計算結果比較均勻的 hash 函數，每次添加 key 的時候，會把 key 通過多次 hash 來計算所得到的位置，如果當前位置不是 0 則表示存在。可以看到，這樣的計算存在一定誤差，這也正是它的不準確性問題的由來。

2. 分布式鎖

大家對分布式鎖也許也不會陌生，現在市面上主流的實現分布鎖的技術有 ZK 和 Redis；下文為大家簡單介紹一下 Redis 如何實現分布式鎖。

命令

setnx lock:mutex ture #加鎖del lock:mutex #刪除鎖 實現分布式鎖的核心就是：請求的時候 Set 這個 key，如果其他請求設置失敗的時候，即拿不到鎖。但是存在一個問題：如果業務 panic 或者忘記調用 del 的話，就會產生死鎖，這個時候大家很容易能想到：我們可以 expire 一個過期時間，這樣就可以保證請求不會一直獨占鎖且無法釋放鎖的邏輯了。

但是假設業務存在這樣一種情況：A 請求在獲取鎖后處理邏輯，由于邏輯過長，這個時候鎖到期釋放了，A 這個時候剛剛處理完成，而 B 又去改了這個數據，這就存在一個鎖失效的問題。解決這種問題參考 CAS 的方式，對鎖設置一個隨機數，可以理解為版本號，如果釋放的時候版本號不一致，則表示數字已經在釋放那一刻改掉了。

三、深入原理

1. IO模型

Redis 是單線程模型（這里的單線程指的是 IO 和鍵值對的讀寫是一個線程完成的），當然如果嚴謹的來說還是可以理解為是多線程，不過這樣的多線程不過是在數據備份的時候會 fork 一個子進程對數據進行從磁盤讀取數據并組裝 RDB，然后同步給 slaver 節點的操作，當然包括備份和持久化也都是通過另外起線程完成的，所以我們可以把 Redis 認作為一個單線程模型。

那么問題來了，為什么單線程的模型能這么快？原因很簡單，因為 Redis 本身就是在內存中運算，而對于上游的客戶端請求，采用了多路復用的原理。Redis 會給每一個客戶端套接字都關聯一個指令隊列，客戶端的指令隊列通過隊列排隊來進行順序處理，同時 Reids 給每一個客戶端的套件字關聯一個響應隊列，Redis 服務器通過響應隊列來將指令的接口返回給客戶端。

Redis IO 處理模型

2. 通信協議

Redis 采用了 Gossip 協議作為通信協議。Gossip 是一種傳播消息的方式，可以類比為瘟疫或者流感的傳播方式，使用 Gossip 協議的有：Redis Cluster、Consul、Apache Cassandra 等。Gossip 協議類似病毒擴散的方式，將信息傳播到其他的節點，這種協議效率很高，只需要廣播到附近節點，然后被廣播的節點繼續做同樣的操作即可。當然這種協議也有一個弊端就是：會存在浪費，哪怕一個節點之前被通知到了，下次被廣播后仍然會重復轉發。

3. 持久化

（1）RDB

RDB 是對當前 Redis 的存儲數據進行一次快照（具體原理和如何做，限于篇幅這里不做過多復述了）。

（2）AOF

日志只記錄 Redis 對內存修改的指令記錄，Redis 提供了一個 bgrewriteaif 的指令對 AOF 進行壓縮。原理就是：開辟一個子進程對內存進行遍歷后，轉換成一系列對 Redis 的操作指令，序列化到一個新的 AOF 日志文件中。系列化完成后再將發送的增量 AOF 日志追加到這個新的 AOF 日志中，追加完成后用新的 AOF 日志代替舊的。

（3）混合持久化

由于單純 RDB 的話，可能存在數據的丟失，而頻繁的 AOF 又會影響了性能，在 Redis 4.0 之后，支持了混合持久化，也就是每次啟動時候通過 RDB+增量的 AOF 文件來進行回復，由于增量的 AOF 僅記錄了開始持久化到持久化結束期間發生的增量，這樣日志不會太大，性能相對較高。

4. 主從同步

Redis 的同步方式有：主從同步、從從同步（由于全部都由 master 同步的話，會損耗性能，所以部分的 slave 會通過 slave 之間進行同步）。

同步過程：

建立連接，然后從庫告訴主庫：“我要同步啦，你給我準備好”，然后主庫跟從庫說：“收到”。

從庫拿到數據后，要把數據保存到庫里。這個時候就會在本地完成數據的加載，會用到 RDB 。

主庫把新來的數據 AOF 同步給從庫。

5. Sentinel

Redis 的主從切換是通過哨兵來解決的。這里哨兵主要解決的問題就是：當 master 掛了的情況下，如果在短時間內重新選舉出一個新的 master 。

Sentinel 集群是一個由 3-5 個（可以更多）節點組成的，用來監聽整個 Redis 的集群，如果發現 master 不可用的時候，會關閉和斷開全部的與 master 相連的舊鏈接。這個時候 Sentinel 會完成選舉和故障轉移，新的請求則會轉到新到 master 中。

6. Redis集群工作原理

Redis 集群通過槽指派機制來決定寫命令應該被分配到那個節點。整個集群對應的槽是由 16384 大小的二進制數組組成，集群中每個主節點分配一部分槽，每條寫命令落到二進制數組中的某個位置，該位置被分配給了哪個節點，則對應的命令就由該節點去執行。槽指派對應的二進制數組如下圖所示：

從上圖可以看到：節點 1 只負責 執行 0 - 4999 的槽位，而節點 2 負責執行 5000 - 9999，節點 3 執行 9999- 16383 。當進行寫的時候：

set key value 命令通過CRC16（key） & 16383 = 6789（假設結果），由于節點 2 負責 5000～9999 的槽位，則該命令的結果 6789 最終由節點 2 執行。當然如果在節點 2 執行一條命令時，假設通過 CRC 計算后得到的值為 567，則其應該由節點 1 執行，此時命令會進行轉向操作，將要執行的命令流轉到節點 1 上去執行。

集群節點同步：集群中每個主節點都會定時發送信息到其他主節點進行同步，如果其他主節點在規定時間內響應了發送消息的主節點，則發送消息的主節點認為響應了消息的主節點正常，反之則認為響應消息的主節點疑似下線，則發送消息的主節點在其節點上將其標記“疑似下線”。

當集群中超過一半以上的節點認為某個主節點被標記為“疑似下線”，則其中某個主節點將疑似下線節點標記為下線狀態，并向集群廣播一條下線消息，當下線節點對應的從節點接收到該消息時，則從從節點中選舉出一個節點作為主節點繼續對外提供服務。

四、Redis為什么變慢了

業務場景中，不知道大家是否碰到過 Redis 變慢的情況：

執行 SET、DEL 命令耗時也很久；

偶現卡頓，之后又恢復正常了；

在某個時間點，突然開始變慢了。

原因分析

查看慢查詢，由于筆者本身機器沒有慢查詢，所以這里看到是空（實在尷尬，這里沒有可用的例子~~）

由于 Redis 在 IO 操作和對鍵值對的操作是單線程的，所以直接在客戶端 Redis-cli 上執行的 Redis 命令有可能會導致操作延遲變大；

使用復雜的命令會讓 Redis的處理變慢，以及CPU過高，例如 SORT、SUNION、ZUNIONSTORE 聚合類命令（時間負責度O（N） ）；

查詢的數據量過大，使得更多時間花費在數據協議的組裝和網絡傳輸過程中；

大 key 查詢，比如對于一個很大的 hash、zset 等，這樣的對象對 Redis 的集群數據遷移帶來了很大的問題，因為在集群環境下，如果某個 key 太大，會導致數據遷移卡頓；

另外在內存分配上，如果一個 key 太大，那么當它需要擴容時，會一次性申請更大的一塊內存，這也會導致卡頓。如果這個大 key 被刪除，內存會一次性回收，卡頓現象會再一次產生。

集中過期，變慢的時間統一，所以業務中的 Key 過期時間盡量在統一的一個時間點加上一個隨機數時間;

內存使用達到上限，當內存達到內存上限的時候，就不許淘汰一些數據，這個時候也可能導致 Redis 查詢效率低；

碎片整理，Redis 在 4.0 版本后會自動整理碎片（由于內存回收過程中存在大量的碎片空間，不整理會導致 Redis 的空間少量浪費），而在整理碎片的過程中會消耗 CPU 的資源，從而影響了請求得到性能；

網絡帶寬，Redis 集群和業務混部，或者并發量過大以及每次返回的數據也很大，網卡帶寬跑滿的情況容易導致網絡阻塞；

AOF 的頻率過高，由于 AOF 需要將全部的寫命令同步，如果同步的間隔比較短，也會影響到 Redis 的性能；

Redis 提供了 flushdb 和 flushall 指令，用來清空數據庫，這也是導致 Redis 緩慢的操作。

五、Redis安全

默認會監聽 6379 端口，最好在 Redis 的配置文件中指定監聽的 IP 地址，更進一步還可以增加 Redis 的 ACL 訪問控制，對客戶指定群組，并限限制用戶對數據的讀寫權限。 訪問 Redis 盡量走公司代理，由于 Redis 本身不支持 SSL 的鏈接，所以走公司代理可以保證安全。客戶端登陸 Redis 必須設置 Auth 秘密登陸。

編輯：jq