本篇內容基於 Redis v7.0 的闡述；官網：https://redis.io/

本篇計劃用 Docker 容器輔助部署，所以需要瞭解點 Docker 知識；官網：https://www.docker.com

系列目錄：

微服務 - 概念 · 應用 · 通訊 · 授權 · 跨域 · 限流

微服務 - 集群化 · 服務註冊 · 健康檢測 · 服務發現 · 負載均衡

微服務 - Redis緩存 · 數據結構 · 持久化 · 分散式 · 高併發

一、分散式解決 Session 的問題

在單站點中，可以將線上用戶信息存儲在Session中，隨時變更獲取信息；在多站點分散式集群如何做到Session共用呢？架設一個Session服務，供多服務使用。

頻繁使用的數據存在DB端，頻繁的DB連接，頻繁的IO；數據存於記憶體中更能減少性能的消耗，更能提高使用效率。

集群化分散式時，為解決以上現象，建立緩存服務顯得尤為重要。

建立緩存服務選擇性很多，如：Redis、MongoDB等，以下以 Redis 為例：

作者：[Sol·wang] - 博客園，原文出處：https://www.cnblogs.com/Sol-wang/

二、記憶體資料庫 Redis

Remote Dictionary Server；
遠程字典服務，Key/Value 存儲系統、列存儲、文檔型存儲等，NoSQL開源記憶體資料庫。最多的使用場景是作為數據緩存，存在於應用與DB之間，減少對DB的訪問，提高數據操作的性能。

下圖展示了緩存服務在整體架構中的位置：

2.1 Redis 特性

高性能 / 高可用 / 持久化 / 集群化，單實例每秒讀寫達10萬次；

豐富的數據類型 ：String / Hash / Set / Zset / 隊列 / 訂閱 / 發佈；

高性能數據結構：SDS / Intset / ziplist / listpack / quicklist / skiplist；

支持 ACL：Access Control List；精細化的許可權管理策略；

單線程處理事務：順序執行，容易上鎖；

多線程處理輔助功能：連接請求 / 持久化等；

單線程處理事務的優缺點

優點：順序執行，不存在臟讀臟寫幻讀等情況，不存在死鎖，不存線上程管理的開銷。
缺點：單線程的性能瓶頸，多處理器的資源浪費。

2.2 單線程IO多路復用

通常情況下，同時連接 Redis 的客戶端有成千上萬的，但 Redis 只有一個主線程處理事務，那如何做到多路連接集中到一個線程處理呢？

當多個客戶端同時發起連接後，這也是需要一個過程的，也是有連接完成的先後，誰連接完成就會告訴 Redis，這裡的告訴用的是回調方式，Redis就會把他的任務放到單一的隊列中，隊列的另一頭連接著主線程。

在這個過程當中，多路的連接彙集到一個有足夠處理能力的隊列中進行傳輸；是不是可以理解為：多路連接重覆利用了單個管道；我想...這裡也是體現了 Redis 的多路復用技術。當然，單單就多路復用來講，也會是多路集中到一路，然後這一路又分成了多路到各各目標。

多路復用也有不同的演算法：select、poll、epoll，Redis用的是epoll演算法，所以其中有回調的動作，目前而言，epoll是最高效的；關於每個具體的演算法，有興趣的同學可以繼續研究一下。

2.3 啟動 Redis

用 Docker 啟動 Redis 簡單示例：

1、拉取鏡像docker pull redis

2、運行容器 docker run -d --name=some-redis redis

3、連接到 Redis docker exec -it some-redis redis-cli

Redis Docker版預設是沒有配置文件的，官網說：可以再生成鏡像方式解決...

既然沒有配置文件，那 Redis 啟動完全是按所有配置項的預設值運行的；如下傳參啟動：

# 啟動 redis-server，多參數配置
docker run -d --name some-redis -p 6379:6379 redis redis-server \
    --bind 0.0.0.0 \        # 支持任意的連接
    --save 60 1 \           # 每60秒 持久化一次
    --protected-mode no \   # 取消保護模式
    --requirepass 123456    # 登錄密碼 123456；連接後用 auth {passwd} 方式登錄

傳參也就是覆蓋了配置項的預設值，以下查看覆蓋後的配置項效果：config get *列出所有配置項

Redis 啟動後，都包含 redis-server / redis-client；
所以任意 Redis 都可用 redis-client 連接到其它 redis-server：docker exec -it some-redis redis-cli -h {目標IP} -p {目標埠}

2.4 重要配置項

通常配置參數於配置文件中；比如：/etc/redis/redis.conf

三、數據類型 / 常用命令

Key/Value 的存儲系統，Key相當於區分的變數名稱，類型區別在於Value；常用數據類型有：

String：字元，基礎類型，過期時長，遞增

• SET/GET key value寫入/取值
• GET key key key取多個值
• INCR/DECR key遞增1/遞減1

List：隊列，先進先出，先進後出

• LPUSH/RPUSH key value頭/尾添加
• LPOP/RPOP key頭/尾移除
• LLEN key隊列長度

Set：無序集合，可查詢 交集、並集、差集等

• SADD|SREM key member member member插入/移除 元素
• SISMEMBER key member是否存在成員
• SINTER key1 key2多集合取交集
• SCARD key元素個數總數

ZSet：帶排序的Set集合；比Set多出一個專用的score值，又可排出名次列

• ZADD key score member score member新增成員及序列數，可覆蓋
• ZRANGE key start stop按序列範圍取集合
• ZRANK key member取正序排名；從0開始的名次
• ZREVRANK key member取倒序排名；從0開始的名次

Hash：可同時設置/獲取多個屬性值

• HSET key field value field value成對設置多個屬性與值
• HMGET key field [field field]取多個列的值
• HINCRBY key field -5指定屬性的值，遞增/遞減

四、數據結構

為什麼 Redis 要有自己的數據結構

• 查詢要快：體現在單條Key用了連續性的記憶體空間
• 占用空間少，節約記憶體：體現在了集合的數據壓縮

Redis 中有這麼幾種數據結構：sds (動態字元串)、hashtable (字典)、linkedlist (鏈表)、intset (整數集合)、ziplist (壓縮列表)、listpack (緊湊列表)、quicklist (混合列表)、skiplist (跳錶)；它們分別應用於Redis各數據類型中，使得Redis在資源利用和運行效率上有著明顯的效果。

以下列出了數據類型與數據結構的應用關係圖：

關於 Listpack；未來作為 Ziplist 的升級替代品，v7.0版本也會有 Ziplist 的存在，後續版本中逐漸被替代。

數據結構的自動切換

每種數據類型也會有多種數據結構，至於何種數據類型在什麼情況下用何種數據結構，取決於存儲的數據；
比如：List 每元素小於8KB時，自動使用 Ziplist，否則自動切換為 Quicklist；
比如：Set 每元素為數字，元素小於512個時，自動使用 Intset，否則自動切換為 Hashtable；
比如：Hash 元素小於512個，每元素長度小於64位元組，自動使用 Ziplist；否則自動切換為 Hashtable。

影響數據結構轉換的配置項

# 配置文件中 各數據類型中的數據結構
# 能承載的最大長度/個數/容量
# 超出最大限制後，變更為其它數據結構
hash-max-listpack-value 64
hash-max-listpack-entries 512
list-max-listpack-size -2(8KB)
set-max-intset-entries 512
set-max-listpack-value 64
set-max-listpack-entries 128
zset-max-listpack-value 64
zset-max-listpack-entries 128

以下主要以 sds / ziplist / listpack / skiplist 為例的闡述，基本涵蓋了重要的數據結構，一些擴展性的數據結構有興趣的同學再深入瞭解下。

4.1 動態字元串 - SDS

很多電腦語言都一樣，Redis 也是基於C語言寫的；對於String類型，當給一個變數拼接一個字元串時，都是以一個新對象在記憶體中重新開闢新的更長的連續空間來存儲；重新開闢/釋放舊空間這樣的記憶體損耗。。。所以為什麼開發人員會避免strname + "xxx"這樣的拼接方式；字元串長度也是底層每次通過遍歷得出的結果。。。Redis為了避免這樣的損耗，於是就有了 Simple Dynamic Strings 這樣的解決方案 SDS。

Redis String 會事先分配好比實際字元串更長的記憶體空間，並記錄實際字元串的長度，也記錄存儲後剩餘的空間長度。

1. 取字元串長度時，直接返回記錄的長度值
2. 追加字元串時，直接使用空閑的剩餘空間

預分配空間有多長？總有用完的時候：

1. 當實際字元串長度<1M時，預分配實際字元串兩倍的連續長度，相當於本次只會占用一半
2. 當實際字元串長度>1M時，每次預分配多出1M的長度空間。便於下次直接存儲
3. 當字元串減少縮短時，多出的剩餘空間保留，便於下次追加，或手動命令清除空閑空間

這種 空間預分配策略 和 惰性刪除策略 就是SDS的性能優勢。

4.2 壓縮列表 - ziplist

一塊連續性的記憶體空間存放了整個Value，也就是一個ziplist，如何做的呢？一個集合的示例：

bytes：記錄 ziplist 的總長度
tail：記錄最後一個 entry 的偏移量，便於快速定位
len：記錄 entry 的總個數
entry：列表元素，數據存放的元素
end：單個 ziplist 的結束符
prevlen：記錄上個 entry 的總長度；這裡記錄值所占用的空間長度，取決於上個 entry 的長度，所以1-5會自動切換
encoding：記錄 data 的實際數據類型 及長度；如：int時占空間小，可直接存到 encoding，就不用 data 了
data：實際數據；占用空間小的數據類型，可直接放到 encoding 中，所以這時候沒有 data 的存在，省空間。

ziplist 的取值：
結構圖中，有總長/個數/偏移量/結束符/上個元素長度；所以 ziplist 正序倒序是都可以算出每個 entry 具體位置並取出數據。

ziplist 的寫入，插/改/刪 統一為覆蓋方式：
1、為新元素找到被覆蓋元素的位置，位置之前的元素 + 新元素 + 位置之後的元素 = 新的ziplist的完整結構
2、申請新ziplist所需長度的記憶體連續空間，並存入新空間
3、釋放舊空間

看起來挺不錯的，相比鏈表的非連續性存儲所帶來的性能提升明顯。。那為什麼還會有新的改進版本 listpack 的出現？

ZIPLIST 的弊端

ziplist 的問題出在 prevlen；
也就是上面藍色部分的描述，存了相鄰 entry 的長度；如果 entry 長度過長，相鄰的 prevlen 所占空間長度就會從1變為5；也就是說 entry 數據變更，會影響到相鄰的 entry；最嚴重的情況是很多entry長度恰好都在一個臨界值，會導致相鄰prevlen長度的變化，連鎖反應是之後位置上的entry級聯性的連續重覆多次變更；
上面提到，變更：就是重新申請新的記憶體連續空間，釋放舊空間；那麼級聯性的連鎖反應呢？一個寫操作，引發的惡性災難事件！！！

4.3 緊湊列表 - listpack

listpack 是 ziplist 的升級版於v7.0中，作為替代品都有什麼變化，listpack結構如下圖：

上圖看出，listpack 與 ziplist 的區別在於：
1、header 取消 tail
2、entry 取消 prevlen
3、當前 entry 中增加 encoding + data 的總長度 element-total-len
4、element-total-len 中的首位會標識出左側是否還有值，主要用於逆序讀

element-total-len 編碼
長度 1-5 bytes 是可變的，不固定長度如何讀出整個 element-total-len？這其中0/1標識了左側是否有數據；

listpack 的讀，假設逆序讀出每個元素的值，已知end固定長度，跳過 1 bytes 到 element-total-len 中讀固定(7)位數，就會知道左側是否有值，這樣會把 element-total-len 整個讀下來，也就知道了當前 entry 長度，那麼也就知道了相鄰 entry 的起始位置；繼續這樣按序把每個 entry 讀出來就完成逆序讀數據。

listpack 的寫入，同樣是基於 ziplist 的方式，新元素替換舊元素組成新的長度，存儲到新申請的記憶體連續空間，釋放舊空間；由於未影響到其它元素，申請一次新空間後完成寫入操作。

這樣以來，listpack 任何寫入的操作，entry 都是在變更自己，不會牽連到其它 entry，這就是對 ziplist 改善的地方。

4.4 跳躍列表 - skiplist

跳錶是在鏈表的基礎上追加了更多指針的存儲；鏈表的指針指向了相鄰元素的地址，但跳錶又追加了指向間隔元素的指針；這使得跳錶在查詢元素的效率上更快。

下表 Linkedlist 與 Skiplist 的查詢區別：

上圖：兩種查詢的路徑不同，影響到的元素數量也不同，鏈表搜了11次才找到指定的元素，而跳錶僅搜了5次就找到了指定的元素。
比如：元素1 既存了指向下個元素2 的指針，也存了指向元素4 的指針；所以跳錶多存的指針讓其可以跳躍搜索，相對於鏈表減少了搜索次數，這就體現了相比鏈表搜索的高效率。

其它數據結構

除以上幾種數據結構外，Redis也會有Intset、quicklist、Hashtable等，由於基本原理相識，這裡簡單描述：
Intset：與ziplist、listpack相似的連續性集合，主要區別在於Intset僅支持數字型；
quicklist：在 ziplist 基礎上擴展的數據結構，其中每個成員是一個ziplist，插入元素時：插入到前個元素ziplist中的末尾、後ziplist的開頭、或獨立的ziplist。

五、持久化

5.1 RDB 模式

Redis Database：持久化以指定的時間間隔執行數據集的時間點的快照整庫備份。

觸發RDB配置：save 36000 1 600 10 30 100
以上從右往左，成對解釋：
  當30秒內寫入了100次，觸發持久化，如果未滿足條件，繼續下一對；
  當600秒內寫入了10次，觸發持久化，如果未滿足條件，繼續下一對；
  當36000秒內寫入了1次，觸發持久化。

持久化過程：記憶體 -> 臨時文件 -> 磁碟。

影響RDB效率的配置項：
  stop-writes-on-bgsave-error yes當持久化失敗後強制停止寫入
  rdbcompression yes快照數據壓縮，損耗CPU
  rdbchecksum yes是否檢測備份文件，損耗CPU≈10%

關閉RDB持久化模式：save ""

模式優劣

優勢：體積小，占用磁碟少。
劣勢：當持久化發生異常時，最後一次的持久化有可能失效，不能確保整體數據的絕對完整性。

5.2 AOF 模式

Append Only File：追加記錄伺服器接收到的每個寫入命令，增量保存；如果寫入錯誤，Redis 也會具有自動修複受損的AOF文件；恢復時，重新按序執行指令，從而重建記憶體庫。

配置開啟AOF模式：appendonly yes

持久化頻率策略配置：appendfysnc always|everysec|no

• 每次命令追加：每次寫命令立刻記錄，太頻繁，太耗性能
• 每秒追加一次：每秒集中記錄一次，依然有可觀的性能表現

文件壓縮 Rewrite
主進程 redis-server 創建出一個子進程 bgrewriteaof 對 AOF文件的重新整理，先整理出一個臨時文件，再覆蓋原AOF文件。

Rewrite 的重寫策略：

• 只針對寫入命令的整理
• 相同數據只記錄最後寫入命令
• 過期數據不記錄
• 多命令合併記錄

多命令合併示例：如累加命令 Incrby 的累加總和合併成一次累加；如集合命令 rpush 的多次追加合併成一次追加多個。

手動觸發執行重寫命令：bgrewriteaof。

自動觸發重寫相關配置：
no-appendfsync-on-rewrite no重寫開關
auto-aof-rewrite-min-size 64mb重寫觸發條件，文件超過指定大小
auto-aof-rewrite-percentage 100重寫觸發條件，文件超過已使用%

AOF文件64MB是不是顯得太小了，可適當增加容量如3GB，以防止過多的觸發壓縮重寫後影響性能；也不可過大，影響數據恢復效率。

模式優劣

優勢：丟失率低，數據較完整。
劣勢：AOF占用磁碟空間大；恢復時重新全部執行一遍命令，恢復速度慢了點；持久化失敗時，最後一秒寫入命令可能丟失。

Redis 預設開啟 RDB，可同時開啟 RDB + AOF，恢複數據時以 AOF 為優先。

由於是單線程方式，Redis 會創建子線程負責持久化處理，不管是哪種持久化方式，在創建子進程的瞬間，都會有阻塞的現象。

六、分散式集群

6.1 虛擬插槽

Redis 分散式給出一個 16384 長度的集合，每個元素稱為一個 Slot，將所有 Slots 分段平均映射到各個 Master 節點上；數據通過對 Key 的演算法映射到各Slot，也就存到了對應的 Master 節點上，所以每個節點實例負責其中一部分的Slot讀寫。

通過控制節點與槽 Slot 的關係，決定每個 Master 節點所承載的數據量；這在集群節點維護的時候非常有用。

6.2 創建集群

集群必須瞭解的conf配置項：

# 每個節點必須的配置項
cluster-enabled yes
# 節點失去連接超時時間
cluster-node-timeout 15000
# 節點間傳輸效率 預設 no（yes:單次多量發送/no:單次少量多次發送）
tcp-nodelay no
# DOCKER/NAT support
# (地址埠可能被轉發)靜態配置公共地址
cluster-announce-ip <外部訪問IP>
cluster-announce-port <外部訪問埠>
cluster-announce-bus-port <節點互通外部埠>

按 Redis 要求的最低 Master 節點數量3實例，多主多從的模式，需要創建6個運行實例：(6371-6376,16371-16376)

# 實例示例1（6371,16371）
docker run -d --name clu-rds-1 \
    -p 6371:6371 -p 16371:16371 \        # 容器分別開放 對外連接埠 和 節點間通信埠
    redis \
    redis-server \                       # 啟動 Redis 服務命令
    --bind 0.0.0.0 \                     # 不限連接的客戶端來源
    --port 6371 \                        # 實例對外連接埠
    --protected-mode no \                # 非保護模式
    --cluster-enabled yes \              # 開啟集群
    --cluster-announce-ip 13.13.1.16 \   # 對外的訪問IP
    --cluster-announce-port 6371 \       # 集群對外的連接埠
    --cluster-announce-bus-port 16371    # 集群節點間通訊埠（通常為：10000+Port）

Docker 查看6個容器實例：

Docker 3主3從模式 創建集群：

docker exec -it clu-rds-1 \
    # 連接到任意實例
    redis-cli -p 6371 \
    # 創建集群 並指定 1主幾從
    --cluster create --cluster-replicas 1 \
    # 要包含的所有(6個)運行實例<ip:port>
    13.13.1.16:6371 13.13.1.16:6372 13.13.1.16:6373 \
    13.13.1.16:6374 13.13.1.16:6375 13.13.1.16:6376

連接到任意容器節點，查看集群成員：docker exec -it <container-name> redis-cli -p <container-port> cluster nodes

6.3 節點管理

# 集群信息
redis-cli -p <port> cluster info
# 查看現有節點成員
redis-cli -p <port> cluster nodes
# 加入新成員，從節點
redis-cli --cluster add-node <new-node-ip:port> <cluster-member-ip:port> \
    --cluster-slave --cluster-master-id <to-master-id>
# 刪除集群成員節點
redis-cli --cluster del-node <del-ip:port> <del-node-id>
# 重新分配節點與插槽映射
redis-cli --cluster reshard <member-ip:port>
# 查看某節點同步信息
redis-cli -p <port> info replication
# 停止某節點實例運行
redis-cli -p <port> shutdown

分散式帶來的影響

事務支持有限；
跨節點的多Key操作有限；如：SET集合不能計算兩KEY的交集等

6.4 分散式鎖

6.4.1 為什麼會需要鎖？