技術文章 » 微服務

微服務

2023-04-18 15:00:41

本篇內容基於 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的存取，提高資料操作的效能。

下圖展示了快取服務在整體架構中的位置：
Redis 記憶體資料庫在整體架構中的位置

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

設定項 說明
bind 可存取限制，白名單；註釋後不限制
port 對外埠
timeout 連線後，沒有通訊任務的空閒時間，超出此時長後自動斷開
daemonize 後臺執行（容器執行時忽略）
protected-mode 只能本地存取的保護模式
tcp-backlog 網路連線佇列最大連線數（對應Linux核心引數 net.core.somaxconn，有關命令sysctl）
tcp-keepalive 網路通訊檢測間隔，網路是否已斷開（當timeout為0才起效吧）
pidfile 存放ProcessID編號的檔案Pid的存放目錄（後臺執行時才會產生pid檔案，容器時是否忽略）
loglevel 紀錄檔級別
logfile 紀錄檔檔案目錄
database 資料庫個數
requirepass Client 連線密碼
maxclients 使用者端同時最大連線數（對應Linux user openfile limit，必設；有關命令ulimit）
maxmemory 記憶體最大使用量，推薦70%

三、資料型別 / 常用命令

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在資源利用和執行效率上有著明顯的效果。

以下列出了資料型別與資料結構的應用關係圖：
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，如何做的呢？一個集合的範例：

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 結構圖
上圖看出，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標識了左側是否有資料；
element-total-len 示意圖

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 的查詢區別：
skiplist 結構圖
上圖：兩種查詢的路徑不同，影響到的元素數量也不同，連結串列搜了11次才找到指定的元素，而跳錶僅搜了5次就找到了指定的元素。
比如：元素1 既存了指向下個元素2 的指標，也存了指向元素4 的指標；所以跳錶多存的指標讓其可以跳躍搜尋，相對於連結串列減少了搜尋次數，這就體現了相比連結串列搜尋的高效率。

五、持久化

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 為什麼會需要鎖？