redis 簡介

Redis 是大家日常工作中使用較多的典型 KV 存儲(chǔ)，常年位居 DB-Engines Key-Value 存儲(chǔ)第一。Redis 是基于內(nèi)存的存儲(chǔ)，提供了豐富的數(shù)據(jù)結(jié)構(gòu)，支持字符串類型、哈希/列表/集合類型以及 stream 結(jié)構(gòu)。Redis 內(nèi)置了很多特性，其中比較重要的有：

• 復(fù)制：Redis 支持異步的全量和增量同步，可以把數(shù)據(jù)從 Master 復(fù)制到 Slave， 實(shí)現(xiàn) Redis 數(shù)據(jù)的高可用。
• 持久化：支持?jǐn)?shù)據(jù)的持久化，可以通過 RDB 和 AOF 機(jī)制實(shí)現(xiàn)數(shù)據(jù)落盤。
• 支持哨兵工具：哨兵工具的主要工作模式是監(jiān)控 Master 節(jié)點(diǎn)的健康狀況。當(dāng)發(fā)現(xiàn) Master 節(jié)點(diǎn)不可用時(shí)，會(huì)主動(dòng)執(zhí)行 Failover， 把 Slave 節(jié)點(diǎn)提升成 Master，保證 Redis 服務(wù)的高可用。
• 提供集群模式：單體 Redis 實(shí)例受限于物理機(jī)內(nèi)存，當(dāng)需要很大的 Redis 集群容量時(shí)，可以使用 Redis 集群模式。Redis 集群模式的原理是把保存在其中的數(shù)據(jù)做了分片，每一部分?jǐn)?shù)據(jù)由不同的 Redis 實(shí)例承擔(dān)。

Redis 的典型應(yīng)用場景有以下 3 種：

• 緩存：因?yàn)?Redis 是基于內(nèi)存的存儲(chǔ)，它的讀寫請求會(huì)在內(nèi)存執(zhí)行，請求響應(yīng)的延遲很低，所以很多場景下會(huì)把 Redis 當(dāng)做緩存使用。
• 數(shù)據(jù)庫：Redis 支持持久化，可以把它當(dāng)做 KV 數(shù)據(jù)庫使用。
• 消息隊(duì)列：Redis 支持 stream 數(shù)據(jù)，在 stream 數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)上封裝了 pub-sub 命令，實(shí)現(xiàn)了數(shù)據(jù)的發(fā)布和訂閱，即提供了消息隊(duì)列的基本功能。

Redis 協(xié)議是二進(jìn)制安全的文本協(xié)議。它很簡單，可以通過 telnet 連接到一個(gè) Redis server 實(shí)例上執(zhí)行 get 和 set 操作。

K8s 簡介

K8s 是一個(gè)容器編排系統(tǒng)，可以自動(dòng)化容器應(yīng)用的部署、擴(kuò)展和管理。K8s 提供了一些基礎(chǔ)特性：

• 自動(dòng)裝箱：可指定 K8s 里 Pod 所需資源的最小值和最大值，即 limit 和 request 的值。K8s 可以根據(jù) request 的值做 Pod 調(diào)度，在一個(gè)節(jié)點(diǎn)上拉起 Pod。
• 服務(wù)發(fā)現(xiàn)與負(fù)載均衡：K8s 提供基于 DNS 的服務(wù)發(fā)現(xiàn)機(jī)制，同時(shí)也提供基于 service 的負(fù)載均衡。
• 自動(dòng)化上線和回滾：這里會(huì)涉及到 K8s 的工作負(fù)載資源。K8s 提供幾種不同的工作負(fù)載資源對應(yīng)不同的業(yè)務(wù)場景。這些不同的工作負(fù)載資源可以實(shí)現(xiàn)服務(wù)的配置變更，例如更新 image、升級 binary、進(jìn)行副本的擴(kuò)縮容等。
• 支持 Deployment/DaemonSet
• 支持 StatefulSet
• 支持 CronJob/Job
• 水平擴(kuò)縮容：K8s 天然支持水平擴(kuò)縮容，可以基于 Pod 的 CPU 利用率、內(nèi)存利用率以及第三方自定義 metrics 對 Pod 進(jìn)行水平動(dòng)態(tài)擴(kuò)縮容。
• 存儲(chǔ)編排：K8s 支持基于 PV 和 PVC 的存儲(chǔ)供應(yīng)模式，可以通過 PV 和 PVC 在 Pod 內(nèi)部使用存儲(chǔ)。
• 自我修復(fù)：舉一個(gè)例子就是副本保持。比如用 Deployment 來托管一個(gè)服務(wù)，如果 Deployment 下的一個(gè) Pod 所在的宿主機(jī)出現(xiàn)了不可用的情況， K8s 會(huì)在可用的節(jié)點(diǎn)上重新拉起一個(gè)新的 Pod 來提供服務(wù)。

現(xiàn)實(shí)工作中遇到的服務(wù)根據(jù)是否需要數(shù)據(jù)持久化可分為有狀態(tài)服務(wù)和無狀態(tài)服務(wù)。不需要數(shù)據(jù)持久化的服務(wù)被認(rèn)為是無狀態(tài)的，包含以下幾種類型：

• API 類服務(wù)：可在任意節(jié)點(diǎn)上執(zhí)行。如果要在 K8s 上部署這類服務(wù)，可使用 K8s Deployment。
• Agent 或 Deamon 類服務(wù)：需要部署在每一臺(tái)機(jī)器上，而且每臺(tái)機(jī)器上最多部署一個(gè)進(jìn)程。在 K8s 上可選擇 DaemonSet 來完成對應(yīng)的部署。
• 還有一類無狀態(tài)服務(wù)對固定的唯一標(biāo)識(shí)有需求。要滿足這些需求，可使用 K8s 的 StatefulSet 來滿足。雖然 StatefulSet 是用來部署有狀態(tài)服務(wù)的，但它可提供固定的唯一標(biāo)識(shí)，也可用來托管無狀態(tài)服務(wù)。

有狀態(tài)服務(wù)需要穩(wěn)定的持久化存儲(chǔ)。除此之外，可能還會(huì)有一些其它的特性要求：

• 穩(wěn)定的唯一標(biāo)識(shí)
• 有序、優(yōu)雅地部署和縮放
• 有序的自動(dòng)滾動(dòng)更新

在 K8s 上，我們一般會(huì)用 StatefulSet resource 來托管有狀態(tài)服務(wù)。

Redis 云原生實(shí)踐

下面將介紹火山引擎 Redis 云原生實(shí)踐。首先我們會(huì)明確 Redis 云原生的目標(biāo)，主要有以下幾個(gè)：

• 資源的抽象和交付由 K8s 來完成，無需再關(guān)注具體機(jī)型。在物理機(jī)時(shí)代我們需要根據(jù)不同機(jī)型上的 CPU 和內(nèi)存配置來決定每個(gè)機(jī)型的機(jī)器上可以部署的 Redis 實(shí)例的數(shù)量。通過 Redis 云原生，我們只需要跟 K8s 聲明需要的 CPU 和內(nèi)存的大小，剩下的調(diào)度、資源供給、機(jī)器篩選由 K8s 來完成。
• 節(jié)點(diǎn)的調(diào)度由 K8s 來完成。在實(shí)際部署一個(gè) Redis 集群時(shí)，為了保證高可用，需要讓 Redis 集群的一些組件滿足一定的放置策略。要滿足放置策略，在物理機(jī)時(shí)代需要運(yùn)維系統(tǒng)負(fù)責(zé)完成機(jī)器的篩選以及計(jì)算的邏輯，這個(gè)邏輯相對比較復(fù)雜。K8s 本身提供了豐富的調(diào)度能力，可以輕松實(shí)現(xiàn)這些放置策略，從而降低運(yùn)維系統(tǒng)的負(fù)擔(dān)。
• 節(jié)點(diǎn)的管理和狀態(tài)保持由 K8s 完成。在物理機(jī)時(shí)代，如果某臺(tái)物理機(jī)掛了，需要運(yùn)維系統(tǒng)介入了解其上部署的服務(wù)和組件，然后在另外一些可用的機(jī)器節(jié)點(diǎn)上重新拉起新的節(jié)點(diǎn)，填補(bǔ)因?yàn)闄C(jī)器宕機(jī)而缺少的節(jié)點(diǎn)。如果由 K8s 來完成節(jié)點(diǎn)的管理和狀態(tài)的保持，就可以降低運(yùn)維系統(tǒng)的復(fù)雜度。
• 標(biāo)準(zhǔn)化 Redis 的部署和運(yùn)維的模式。盡量減少人工介入，提升運(yùn)維自動(dòng)化能力，這是最重要的一點(diǎn)。

Redis 集群架構(gòu)

下面介紹一下我們的 Redis 集群架構(gòu)。集群里有三個(gè)組件：Server、Proxy 和 Configserver，分別完成不同的功能。

• Server：存儲(chǔ)數(shù)據(jù)的組件，即 Redis Server，其后端部署模型是一個(gè)多分片的模型。分片之間的 Server Pod 沒有通信，為 share-nothing 的架構(gòu)。分片內(nèi)部為一主多從的模式，可以一主一從、一主兩從，甚至更多。
• Proxy：承接 client 發(fā)來的請求，同時(shí)根據(jù)讀寫拓?fù)洌颜埱筠D(zhuǎn)發(fā)給后端的 Server 分片。
• Configserver：配置管理組件，本身是無狀態(tài)的，所有的狀態(tài)信息都存儲(chǔ)在 etcd。集群生命周期里 Server 所有的分片信息都保存在 Configserver 里。Configserver 會(huì)對每一個(gè)分片的 Master 節(jié)點(diǎn)進(jìn)行定期探活，如果發(fā)現(xiàn)某一個(gè)分片的 Master 節(jié)點(diǎn)不可用，就會(huì)執(zhí)行 Failover，把分片內(nèi)可用的 Slave 提成新的 Master，保證分片可繼續(xù)對外提供服務(wù)。同時(shí)，Configserver 也會(huì)定期根據(jù) Failover 或其他一些實(shí)例信息的變更來更新自己的讀寫拓?fù)潢P(guān)系，保證 Proxy 可以從 Configserver 拉取新的正確的配置。

結(jié)合以上介紹的 Redis 架構(gòu)以及 K8s 的特性，我們抽象了一個(gè) Redis 集群在 K8s 集群上部署的基本形態(tài)：

• 使用 Deployment 將無狀態(tài)的 Configserver 部署在 K8s 上。因?yàn)?Configserver 可被所有 Redis 集群共用，為了簡化運(yùn)維復(fù)雜度，我們規(guī)定所有的 Redis 集群共用一個(gè) Configserver。
• Proxy 也是無狀態(tài)的組件，也用 Deployment 來部署。
• 因?yàn)槲覀冇卸喾制?，而?Server 是有狀態(tài)的，所以每一個(gè)分片用 StatefulSet 進(jìn)行托管。在新建集群時(shí)，我們默認(rèn)分片內(nèi)的 0 號 Pod 為 Master Pod，其余所有的 Pod 是 Slave。這是一個(gè)初始狀態(tài)，后續(xù)可能會(huì)跟隨 Failover 或其他異常發(fā)生變更，但是 Configserver 里會(huì)實(shí)時(shí)記錄最新的狀態(tài)信息。

Redis Server 啟動(dòng)的時(shí)候需要一些配置文件，里面涉及到一些用戶名和密碼，我們是用 Secret 來存儲(chǔ)的。在 Server Pod 運(yùn)行的時(shí)候通過 volume 機(jī)制掛載到 Server Pod 內(nèi)部。

對于 Proxy，通過 HPA，基于 Proxy 的 CPU 利用率，支持 Proxy 服務(wù)的動(dòng)態(tài)擴(kuò)縮容。

放置策略

對于一個(gè) Redis 集群涉及到的 Server 和 Proxy 組件，我們有一些放置策略的要求，比如：

• 同一個(gè) Server 分片下的節(jié)點(diǎn)不能在同一臺(tái)機(jī)器上，即，一個(gè)分片內(nèi)的主從節(jié)點(diǎn)不能在同一臺(tái)機(jī)器上。轉(zhuǎn)換成 K8s 里面的模型，即我們希望一個(gè) StatefulSet 下所有的 Pod 部署在不同的機(jī)器上。我們會(huì)利用 Pod-AntiAffinity 下面的 required 語義，來保證 StatefulSet 下所有的 Pod 都部署在不同的機(jī)器上。
• 一個(gè)集群下的 Proxy Pod 需要盡可能分布在不同的機(jī)器上，可通過 Pod-AntiAffinity 下的 preferred 語義加上拓?fù)浞植技s束來滿足。preferred 語義只能保證 Pod 盡可能分布在不同的機(jī)器上，為了避免極端情況下所有 Pod 都在同一臺(tái)機(jī)器上的情況，我們會(huì)使用拓?fù)浞植技s束。

存儲(chǔ)

存儲(chǔ)使用的是 PVC 加 PV 再加上具有動(dòng)態(tài)供給能力的 StorageClass。使用 StorageClass 是為了抽象不同的存儲(chǔ)后端，可支持本地磁盤和分布式存儲(chǔ)?？梢酝ㄟ^ StorageClass 的配置直接申請對應(yīng)的存儲(chǔ)，不用了解具體后端的實(shí)現(xiàn)。

另外，我們使用的是支持動(dòng)態(tài)供給的 StorageClass，可自動(dòng)按需創(chuàng)建不同大小的 PV。如果使用靜態(tài)供給，就無法提前預(yù)知所有 Redis 實(shí)例的規(guī)格，也無法把它們對應(yīng)的指定數(shù)量的 PV 都創(chuàng)建出來。

Redis 云原生功能介紹

Redis 云原生化以后，Operator 組件是基于 Operator Pattern 實(shí)現(xiàn)的一個(gè) custom controller，主要用于編排 Redis Cluster resource，管理 Redis 集群的一些變更。Configserver 也部署在 K8s 上，所有跟 Redis 相關(guān)的組件都是云原生化的。

新建集群

1. 對于常見的新建集群的請求，會(huì)先發(fā)給 ApiServer。ApiServer 接收到請求之后，會(huì)通過 client go 的 watch 機(jī)制讓 Operator 感知到。
2. 隨后 Operator 會(huì)請求 ApiServer 創(chuàng)建對應(yīng) Server 的 StatefulSet。
3. K8s 把所有 Server 的 StatefulSet 創(chuàng)建成功之后，等所有的 Pod 都處于 ready 狀態(tài)，這時(shí)所有分片內(nèi)的 Server Pod 之間是沒有主從關(guān)系的。
4. Operator 感知到所有的 StatefulSet 都已經(jīng)處于 ready 的狀態(tài)之后，會(huì)獲取所有 Server Pod 信息，并注冊到 Configserver。
5. Configserver 接下來會(huì)連接到所有分片內(nèi)的 Slave 節(jié)點(diǎn)，執(zhí)行實(shí)際的 SLAVEOF 命令，保證建立真正的主從關(guān)系。
6. Operator 會(huì)定期查詢 Configserver 里建立主從關(guān)系的進(jìn)度。等所有分片的主從關(guān)系建立成功之后， Operator 會(huì)請求 ApiServer 把對應(yīng)的 Proxy 創(chuàng)建出來。
7. Proxy 創(chuàng)建出來之后，會(huì)去 Configserver 拉取最新的拓?fù)洌ＷC對外提供服務(wù)的時(shí)候可以把請求打給后端正常的分片。

分片擴(kuò)容

在實(shí)際使用的過程中如果遇到容量不足的情況，需要進(jìn)行水平擴(kuò)容。分片擴(kuò)容的請求也是類似的：

1. 請求發(fā)給 ApiServer。
2. ApiServer 把請求推送給 Operator。
3. Operator 感知到之后，會(huì)先給 ApiServer 發(fā)請求，把新的分片對應(yīng)的 StatefulSet 創(chuàng)建出來。
4. K8s 會(huì)把新分片的 StatefulSet 創(chuàng)建好，在處于 ready 狀態(tài)之后，一個(gè) StatefulSet 下的每個(gè) Pod 也都是獨(dú)立的狀態(tài)，沒有建立真正的主從關(guān)系。
5. Operator 獲知新創(chuàng)建的 Server StatefulSet 分片已經(jīng)處于 ready 狀態(tài)之后，會(huì)把新的 Server 分片的實(shí)例地址注冊到 Configserver。Configserver 現(xiàn)在會(huì)有兩個(gè)階段：
6. 第一步：指導(dǎo)新分片內(nèi)真實(shí)主從關(guān)系的建立。即連到所有的新分片的 Slave 上，執(zhí)行 SLAVEOF 的命令；
7. 第二步：指導(dǎo)數(shù)據(jù)從老分片遷移到新分片。這樣新的分片才能發(fā)揮作用，這一步很重要。
8. Operator 會(huì)一直檢查數(shù)據(jù)遷移或者 rebalance 的進(jìn)度。等進(jìn)度結(jié)束之后，Operator 會(huì)更新 Redis Cluster 里 status 的字段，反映出來當(dāng)前的分片擴(kuò)容的操作已經(jīng)結(jié)束了。

分片縮容

分片縮容的流程和分片擴(kuò)容類似：請求先發(fā)送給 ApiServer，Operator 會(huì)感知到請求，然后把縮容分片的請求發(fā)送給 Configserver。

Configserver 此時(shí)做的事情是：

1. 先指導(dǎo)數(shù)據(jù)遷移?？紤]到后邊的一些分片下線，需要把分片上的數(shù)據(jù)先遷移到其他可用分片上，保證數(shù)據(jù)不丟。
2. Operator 會(huì)一直查詢 Configserver 指導(dǎo)的數(shù)據(jù) rebalance 的進(jìn)度。等縮容操作在 Configserver 完成之后，Operator 會(huì)請求 ApiServer 執(zhí)行真正的 Server StatefulSet 刪除，這時(shí)才是安全的刪除操作。

組件升級

一個(gè) Redis 集群會(huì)涉及到兩個(gè)組件：Proxy 和 Server。

無狀態(tài)的 Proxy 用 Deployment 托管，如果要進(jìn)行組件升級，直接升級對應(yīng)的 image 即可。

Server 是一個(gè)有狀態(tài)的組件，它的升級流程相對來說復(fù)雜一點(diǎn)。為了簡化流程，我們以 Server 只有 1 分片的 Redis 集群為例，介紹升級過程。

1. Server 組件的升級請求發(fā)送給 ApiServer，ApiServer 接收到這個(gè)請求之后會(huì)把它推送給 Operator。
2. Operator 首先會(huì)按照分片內(nèi) Pod 編號從大到小的順序選擇要升級的 Pod。
3. 選定 Pod 之后，會(huì)把它從 Configserver 的讀拓?fù)淅镎簟＃ㄈ绻倪@個(gè) Pod 在集群拓?fù)淅锸?Master，我們會(huì)先調(diào)用 Configserver 的 API，執(zhí)行 Failover，把它變成 Slave，然后再把它從讀的拓?fù)淅镞吔o摘除掉。）
4. 之后，Operator 等待 30 秒。這個(gè)機(jī)制的出發(fā)點(diǎn)是：
5. 首先，Proxy 去 Configserver 拉取配置是異步過程，可能需要經(jīng)過至少一輪的數(shù)據(jù)同步才能正常拿到數(shù)據(jù)。等待 30 秒主要是為了保證所有的 Proxy 都已經(jīng)拿到了最新的讀拓?fù)?/strong>，新的讀請求不會(huì)再發(fā)送到要升級的 Server 節(jié)點(diǎn)上。
6. 另外，我們要保證等待 30 秒的時(shí)間，讓已經(jīng)被要升級的 Server Pod 接收的這些請求都成功地被處理，并且返回之后，才能把要升級的 Server Pod kill 掉。
7. 30 秒之后請求 ApiServer 執(zhí)行實(shí)際的 Pod 刪除操作。刪除之后 K8s 會(huì)重新調(diào)度一個(gè)新的 Pod 起來，這時(shí)新創(chuàng)建的 Server Pod 也是一個(gè)獨(dú)立的 Server 的狀態(tài)，沒有跟任何節(jié)點(diǎn)建立主從關(guān)系。Operator 感知到新的 Server Pod 已經(jīng)處于 ready 的狀態(tài)，會(huì)把它注冊到 Configserver。
8. Configserver 連到新的 Server Pod 上，根據(jù)它所處的分片跟所在分片的 Master 節(jié)點(diǎn)建立主從關(guān)系，同時(shí)進(jìn)行數(shù)據(jù)同步。
9. Operator 會(huì)定期檢查新的 Server 分片在 Configserver 是否已經(jīng)完成數(shù)據(jù)同步。如果是，Operator 才會(huì)認(rèn)為一個(gè) Server Pod 完成了升級。該分片內(nèi)其他所有 Server pod 的升級流程都是類似的，直到該分片內(nèi)所有 Server Pod 都升級完，才認(rèn)為這個(gè)分片升級完成。最后 Operator 會(huì)更新自己 Redis Cluster 的 CRD 里對應(yīng)的 Status 狀態(tài)信息，反映當(dāng)前組件升級的流程和變更操作已經(jīng)結(jié)束了。