大家好，我是張晉濤。

前段時間看到了很多關於數據庫要不要部署在 Kubernetes 之上的討論，這些年，這種討論時有發生。

這個事情並沒有絕對的定論，因為每個人都是基於自己的認知，或基於自己過往的經驗在進行分析、討論，每個人的出發點不同，自然得到的結論也是不一樣的。

2021 年的時候，我曾經做過一次線上分享： Redis 容器化技術選型，K8S 並非唯一 | MoeLove 在那次分享中，我主要是聊了一些容器化的技術手段，Redis 自身的一些特性，以及基於不同業務場景或者需求時，可以選用的技術方案。

今天這篇，我想再聊聊 Redis 在 Serverless 場景下的應用。

Redis 的特性及應用場景

Redis 是一個開源的，基於內存的數據存儲引擎。它非常簡潔，但功能全面實用、靈活多變，常被稱之為數據庫領域的 “瑞士軍刀”，被數百萬開發者用作數據庫、緩存、流引擎和消息代理。

Redis 的主要特點

• 速度快：由於它是一個內存型數據庫，數據的讀取寫入都直接通過內存完成，避免了讀寫硬盤而可能造成的延遲問題。即使在高頻的讀寫場景下也可以有非常不錯的表現；
• 適用場景豐富：Redis 有着豐富的數據類型，可以靈活的用於各類場景中（下文將詳細介紹）；
• 上手成本低：Redis 的操作指令和使用是非常簡單的，包括它的通信協議 RESP 也設計的非常簡潔，感興趣的小夥伴可以參考我之前的文章 理解 Redis 的 RESP 協議 | MoeLove；
• 支持持久化：儘管 Redis 是內存型數據庫，但是考慮到實際的應用場景，如果能對數據進行持久化，那麼在遇到故障或者數據恢復時則會方便很多。Redis 支持通過 RDB（內存數據快照） 和 AOF （記錄 Server 端的命令到文件）的方式進行持久化；
• 生態豐富：Redis 有着 50+ 種語言的 Client library，覆蓋了所有的主流編程語言。同時也有很多 CLI 和 GUI 的客户端工具可以使用；

Redis 支持的數據類型及適用場景

前面提到 Redis 有着非常豐富的數據類型，每種數據類型都有特定的應用場景。

1. 字符串（string）：字符串是 Redis 最基本的數據類型，字符串類型支持的常用命令包括 SET、GET 等；
2. 散列（hash）：散列表是一種 K-V 型的數據結構，散列類型可以存儲多個鍵值對，並且支持嵌套數據結構。散列類型支持的常用命令包括 HSET、HGET 等；
3. 列表（list）：列表在每個節點存儲了一個字符串，可以在列表的兩端進行元素的添加或刪除操作。列表類型支持的常用命令包括 LPUSH、RPUSH、LPOP 和 RPOP 等；
4. 集合（set）：集合是一個不允許有重複元素的無序數據結構，支持取交集、並集和差集等常用操作。集合類型支持的常用命令包括 SADD、SMEMBERS 等；
5. 有序集合（zset）：有序集合是一個可以排序的集合，每個元素都有一個 score，支持根據 score 進行排序和範圍查找。有序集合類型支持的常用命令包括 ZADD、ZRANGE、ZREVRANK 和 ZSCORE 等；
6. 位圖（bitmap）：位圖不是個實際的數據類型，是一個由二進制位組成的數組結構，支持位運算操作。位圖常用於統計、記錄用户的在線狀態等場景；
7. 位域（bitfield）：位域也是一種用於操作二進制位的數據結構和命令集合。允許用户以比特位為單位對字符串進行操作，並且支持多種位操作，例如獲取、設置、計數等。位域也可以用於存儲和操作布爾值、整數等數據類型；
8. HyperLogLog：HyperLogLog 是一種基數算法，用於估算一個集合的基數。它採用的是隨機化算法，並且空間複雜度很低。 HyperLogLog 可用於處理大量數據集的場景，例如網站的 UV 統計；

Redis 支持這麼多的數據類型和用法，使得它常年穩居 K-V 型存儲排行榜的榜首。以下是我新截圖的排名：

Redis 集羣的架構

Redis 除了支持 master-replica 這種簡單的主從模式外，也提供了 Cluster 模式。

Redis Cluster 是 Redis 數據庫的分佈式解決方案。它可以將數據分佈在多台服務器上，從而提高 Redis 的可用性和性能。

Redis Cluster 採用了分片的方式來存儲數據，將數據分散在多個節點上。每個節點都存儲一部分數據，並且每個節點都知道其他節點的信息。這樣，當一個節點宕機時，其他節點可以接管它的數據，保證 Redis 集羣的可用性。

同時，由於 Redis Cluster 的這種特性，也使得它可以通過增加節點的方式來對集羣的容量進行擴展，這解決了單實例或者主從模式下，Redis 受限於所在機器內存容量限制的不足。

並且每個節點仍然可以採用主從的模式，提高其整體的可用性。

Serverless 化的 Redis 有何優勢

前面簡單的介紹了下 Redis 的主要特性和它的集羣模式。我們會發現 Redis Cluster 有一個天然的優勢 -- 它可以進行水平擴展，從而提升集羣的整體容量。

在 Redis Cluster 出現之前，我們的大多數生產環境都是在使用 master-replica 這種主從模式。使用主從模式時候存在一些痛點，關於故障轉移之類的我這篇文章中就不談了，我主要談下關於容量的部分。

在每次業務申請新上 Redis 主從集羣的時候，第一件事情就是需要描述清楚業務場景，用途，以及預期的容量（或者預估的增長速度）。這樣才能去找到合適的機器進行集羣的部署。

在後續使用過程中，正常情況下會為數據設置 TTL 進行過期，但隨着業務的發展，仍可能會導致集羣容量逐步增加，當它快要達到容量的 80% 時候，就必須要擴容了。如果機器上尚有空餘的內存，那麼只需要修改 maxmemory 配置即可，但如果機器上內存容量不足，那隻能進行集羣的遷移了。到遷移時，同樣涉及到了容量的規劃，機器的採購等一系列繁瑣的事情，苦不堪言。

那如果我們採用 Serverless 化的 Redis 能帶來哪些優勢呢？

無需選擇實例大小

無論是使用物理機也好，或者在選擇雲廠商提供的數據庫 / Redis 實例也罷，通常情況下都需要對容量有一個大致的評估，以及增速的評估，然後從一大堆的實例類型的列表中進行選擇。

不同的實例類型則對應不同的內存容量，網絡吞吐等，這需要耗費很多的時間，而且為了能在保障業務不受影響的同時優化成本，還需要專門對於不同類型的實例進行壓測，看看是否能滿足預期，最終才能確認選擇哪個實例。

另外，業務的增長有時候會存在不確定性，一旦業務出現爆發式增長，有些平台不提供擴容能力，就只能遷移了。另一種情況是，一些平台只允許進行規格升級，不允許降級，這樣在業務低峯期的時候，也就造成了浪費。

使用 Serverless Redis 就無需花時間去進行這種實例的選擇了，它可以根據業務的實際情況，進行動態的水平、垂直伸縮，這就方便很多了。創建時候也只需要指定最基本的信息就足夠了。

計費靈活

傳統的固定實例類型的計費方式，通常都是直接按照選定的實例大小進行計費的。這種模式下，即使用量很少，也需要為尚未使用的資源進行付費。

但是在 Serverless 模式下，則只需要按用量進行付費即可。

下圖是亞馬遜雲科技 AWS ElastiCache For Redis （Serverless 版）的計費模式，主要按照兩個維度：

• 數據存儲：按照數據存儲的時間（GB - 小時）進行計費，最小單位是 1 GB；
• ECPUs：指的是 ElastiCache 處理消耗的計算單元，如果在空閒時間是這部分是不產生費用的；

彈性伸縮和高可用

在 Serverless 模式下，一旦發現某個實例的負載較高，或者健康狀態異常，則可以立刻進行擴容，保證整體的可用性。而且也無需擔心容量限制的問題。

同樣的，如果負載較低，則可以進行縮容，來節約成本。

AWS ElastiCache for Redis (Serverless)

最近在亞馬遜雲科技 AWS re:Invent 大會上新推出一款 AWS ElastiCache for Redis (Serverless 版) 服務，恰好就是我這篇文章中的實踐。

我看到這個服務發佈後，趕快進行了一些嘗試，以下是我個人覺得的一些重點。

TLS 連接

在亞馬遜雲科技 AWS 上創建這個服務的時候，會有一些選項，其中我注意到有個 Encryption in transit 這個是默認開啓的，並且在創建後也是不允許修改的。

這個特性表明在傳輸時需要使用 TLS 連接，來保證安全。在我們編譯安裝 redis-cli 工具的時候，就需要使用 make BUILD_TLS=yes 了，這樣編譯安裝後，redis-cli 就可以使用 --tls 參數進行連接了，否則會出現連接失敗的情況。

替代的方式可以使用 openssl s_client -connect IP:Port 這樣進行連接。

用户權限

在 Security groups 這裏，默認是不開啓用户認證的。可以在這裏修改，創建新的 Security group，並創建用户，這樣就可以開啓用户認證了。

網絡

默認創建後的 endpoint 是一個 VPC 的內網地址，如果需要在外部訪問則需要創建 NAT Gateway，或者用其他方式進行轉發。

我在相同 VPC 下開了另一個 EC2 實例跑了下 benchmark，效果如下：

控制枱上也有相關指標可以看到完整的 benchmark 後的資源消耗情況：

總結

由於 Redis Cluster 架構的靈活性，如果是將它用作 cache，使用 Serverless 的模式能帶來不少的優勢，提升整體服務的可用性，並且還可以減少最初容量規劃上的耗時。

我覺得這將會是一種趨勢。

本文參與了「構」向雲端 | 亞馬遜雲科技 x 思否 2023 re:Invent 構建者徵文大賽，歡迎正在閲讀的你也加入。

授權聲明：本篇文章授權活動官方亞馬遜雲科技文章轉發、改寫權，包括不限於在 Developer Centre，知乎，自媒體平台，第三方開發者媒體等亞馬遜雲科技官方渠道