本文作者：於雨
目前任職於 360 智匯云云平臺基礎架構部，dubbogo 社群負責人， OpenAtomFoundation/pika 專案負責人，前螞蟻集團 seata 專案負責人。從業⼗四年來⼀直在服務端基礎架構工作，熱愛開源，陸續參與和改進過 Redis/Pika/Muduo/dubbo/dubbo-go/Sentinel-golang/Seata-go 等知名項⽬。先後榮獲諸多榮譽，阿⾥ 2021 年開源先鋒⼈物，2022 開放原子全球開源峰會 “程式碼貢獻之星” ，2022 年度 "OSCAR 尖峰開源人物”，代表作 dubbo-go 榮獲 2021年科創中國 “年度優秀開源產品” 大獎。過去有很多小夥伴一直很好奇 KubeBlocks 如何幫助資料庫輕鬆上雲，今天小猿姐邀請了來自 PikiwiDB 的小夥伴於雨來給大家手把手教學，一起來看 PikiwiDB 如何藉助 KubeBlocks 的經驗和抽象能力，在雲環境中實現高效、便捷的部署和管理。

過去有很多小夥伴一直很好奇 KubeBlocks 如何幫助資料庫輕鬆上雲，今天小猿姐邀請了來自 PikiwiDB 的小夥伴於雨來給大家手把手教學，一起來看 PikiwiDB 如何藉助 KubeBlocks 的經驗和抽象能力，在雲環境中實現高效、便捷的部署和管理。

一、PikiwiDB(原 Pika) 介紹

PikiwiDB(原 Pika) 是一個以 RocksDB 為儲存引擎的的大容量、高效能、相容 Redis 協議、資料可持久化的彈性 KV 資料儲存系統，支援 Redis 常見資料結構，如 string/hash/list/zset/set/geo/hyperloglog/pubsub/bitmap/stream 等。

當 Redis 記憶體使用超過閾值（例如 16GiB）時，會面臨記憶體容量有限、單執行緒阻塞、啟動恢復時間長、記憶體硬體成本貴、緩衝區容易寫滿、一主多從故障時切換代價大等問題。PikiwiDB(原 Pika) 力求在完全相容 Redis 協議、繼承 Redis 便捷運維設計的前提下，透過持久化儲存的方式解決了 Redis 一旦儲存資料量巨大就會出現記憶體容量不足的瓶頸問題，並且可以像 Redis 一樣，支援使用 slaveof 命令實現主從模式，還支援資料的全量同步和增量同步。還可以用 twemproxy or Codis 實現靜態資料分片。

PikiwiDB(原 Pika) 作為現代資料庫，積極迎合雲端計算趨勢，追求分鐘級交付、極大容量、極高效能、極好彈性以及雲平臺提供的資料穩定性和安全性。在實現這些能力的探索中，藉助 KubeBlocks，我們更輕鬆地解決了雲化過程中遇到的問題。

為了更好地理解這些問題，讓我們從簡要介紹 PikiwiDB(原 Pika) 叢集架構開始。

PikiwiDB(原 Pika) 叢集採用 Codis 的方案，包括控制面和資料面。控制面有前端 fe、控制中心 dashboard 以及儲存配置資訊的 ETCD 叢集。資料面有用於分發資料的代理 proxy 和 PikiwiDB(原 Pika) 主從例項。每組主從例項形成一個 group，相當於一個分片，由 dashboard 管理。PikiwiDB(原 Pika) 社群對 Codis 進行改造，如為了減少元件，將高可用元件 Redis-Sentinel 融合至 dashboard 中。

二、關鍵改進

在雲化過程中，我們面臨諸多挑戰，首要問題是叢集模型的抽象。

2.1 叢集抽象

整個叢集元件繁多，無論是部署維護還是簡單試用，這種複雜度會讓人望而卻步。將叢集部署到 Kubernetes 中，直接使用 StatefulSet 等物件難以滿足 PikiwiDB(原 Pika) 叢集對狀態管理的需求。其中大量地址和變數需要管理，即便使用 Helm 也需花費較長時間除錯上線。

社群曾嘗試為 PikiwiDB(原 Pika) 開發 operator 以實現快速部署，但在將有狀態叢集抽象成簡單配置的過程中遇到了困難，進展緩慢。容器有許多固定和可變引數，如 Volume、mount 地址、PVC 的 storage class 等。在將一完整 YAML 抽象成可重複部署、可多環境部署的 Helm 時，會遇到很多這種問題，如何將不同的引數，抽象至不同的層，需要平衡靈活性和易用性。

在探索調研中，於 2023 年 6 月正式開源的 KubeBlocks 吸引了我們的注意：

KubeBlocks 是一個基於 Kubernetes 的雲原生資料管理平臺，旨在為使用者提供一種便捷的方式來管理和運維關係型資料庫、NoSQL 資料庫、向量資料庫以及流計算系統。KubeBlocks 的名字來源於 Kubernetes 和 LEGO 積木，這表明在 Kubernetes 上構建資料庫和分析型工作負載既高效又愉快，就像玩樂高玩具一樣。

KubeBlocks 將雲服務提供商的大規模生產經驗與增強的可用性和穩定性改進相結合，幫助使用者輕鬆構建容器化、宣告式的關係型、NoSQL、流計算和向量型資料庫服務。

KubeBlocks 還具有以下優勢：不必學習資料庫調優，充分利用儲存和計算資源，實現資料庫效能；在節點或可用區級別提供容錯能力，確保資料丟失或服務中斷的風險降到最低。

起初我們只是想學習一下，然後完善自己的 operator。但調研完畢後，發現 KubeBlocks 團隊將雲廠商經驗融入軟體中，提供了在 Kubernetes 上抽象有狀態叢集的解決方案，更瞭解到 KubeBlocks 背後的團隊是原 PolarDB 創始團隊後，我們決定直接放棄自己的 operator，完全採用 KubeBlocks 實現 PikiwiDB(原 Pika) 叢集的雲原生化。透過藉助其經驗和抽象能力，我們輕鬆實現了各個元件的雲化部署。

KubeBlocks 將叢集分為三層：細粒度的元件 Component、叢集定義 ClusterDefinition、叢集例項配置 Cluster。它將分散式模型、配置、指令碼、儲存、監控、備份等功能抽象至不同層，使叢集能夠良好對映至 Kubernetes。KubeBlocks Addon 支援多種擴充套件方式，目前主流的擴充套件方式是 Helm。建立叢集的 Helm Chart，PikiwiDB(原 Pika) 基本上只用按照 KubeBlocks 的定義給出各個元件的 YAML 檔案即可，用一個叢集 YAML 模板檔案用來定義叢集拓撲、元件配置和元件啟動指令碼，即可迅速拉起一個叢集。

目前所有 Pika YAML 檔案都在 GitHub 倉庫放著，按照 Readme 文件即可迅速實現叢集的部署以及叢集的擴容。

KubeBlocks 內建的許多功能也為後續的完善提供了很好的思路，隨著其發版更新，我們社群會及時跟進。

2.2 狀態管理

YAML 檔案只是在 Kubernetes 上部署了一個 PikiwiDB(原 Pika) 叢集，但 PikiwiDB(原 Pika) 作為一個資料庫，是一個有狀態的叢集，所以 Operator 還需要維護叢集的狀態。為了說明問題，讓我們簡要介紹一下 PikiwiDB(原 Pika) 叢集的 slot 管理。

Codis 將整個叢集以 Slot 為單位分成 1024 個 Slots，PikiwiDB(原 Pika) 對 Slot 數量進行了擴容，原理相似。每組 Pika-group 儲存不同的 Slots，Slots 的 index 儲存在 dashboard 中。proxy 從 dashboard 獲取 Slots 的 Index，當使用者請求到達 proxy 時，它會根據 Slots 的 index 路由請求。

對 PikiwiDB(原 Pika) 叢集進行擴容時，需要按一定順序執行：

增加新的 group；
等組建立完成後，通知 dashboard 進行 slot 搬遷。

在縮容時也需要進行反向操作，先搬遷，待搬遷完成後再進行縮容，以避免資料損失。

只使用 Kubernetes 本身的機制，很難實現這樣的操作。例如，在整個 PikiwiDB(原 Pika) 主從例項組全部正常執行後，再使用某種機制呼叫 dashboard 進行擴容。而使用 KubeBlocks，只需在 Component 中新增一個 postStartSpec。建立完成 group 後，KubeBlocks 觸發一個 Job 執行後續任務，整個過程非常優雅。

2.3 功能驗證

本節給出一個實操流程，以 step by step 的方式，詳述如何在 macOS 上部署一個可在 Kubernetes 上執行的 PikiwiDB(原 Pika) 叢集。

啟動 Docker

  open -a Docker

部署 k8s 叢集（以 KIND 替代）

  brew install kind
  kind create cluster

安裝 KubeBlocks

  curl -fsSL | bash   # 下載 kbcli
  kbcli kubeblocks install --version 0.5.3 -v1   # 下載  kubeBlocks
  kbcli kubeblocks status # 檢查 KubeBlocks 狀態

部署叢集

  cd ./tools/kubeblocks-helm/  # 
  helm install pika ./pika    # 下載 Pika
  helm install pika-cluster ./pika-cluster  # 部署 cluster
  kubectl get pods --all-namespaces -o wide  # 檢視 cluster 狀態，或者使用命令 kubectl get cluster --watch

訪問叢集

  kubectl port-forward svc/pika-cluster-codis-fe 8080  # 訪問 codis-fe，轉發暴露 codis-fe 到 8080 埠
  kubectl port-forward svc/pika-cluster-codis-proxy 19000 # 連線到 proxy 訪問 pika-cluster
  redis-cli -p 19000  # 連線到 codis
  kbcli cluster hscale pika-cluster --replicas 4 --components pika # 水平擴容增加 2 個 Pika 例項

三、下一站

基於 KubeBlocks 的 Operator 幫助 PikiwiDB(原 Pika) 叢集實現了上雲以及節點的擴容，但上 K8s 僅僅是雲化的初步 -- 上雲，要實現一個雲原生的 PikiwiDB(原 Pika) 叢集，還需要對 PikiwiDB(原 Pika) 進行架構改造，才能為使用者提供更加靈活、按需的資料庫服務，提高資源利用率，使使用者無需關心底層基礎設施的維護和管理。

PikiwiDB(原 Pika) 雲化關鍵技術點如下：

1. 儲存結構

目前 PikiwiDB（原 Pika）的資料儲存結構包括以下幾個方面：

使用 RedisCache 在記憶體中快取熱資料，以提高讀取效率。
使用 RocksDB Block Cache 快取溫資料，以實現更高效的讀取操作。
關閉 RocksDB 的 Write-Ahead Log (WAL)，保留 binlog 機制，並將 RocksDB WAL kPointInTimeRecovery 級別崩潰恢復機制加到 binlog 上，以確保資料安全性。
使用位於 SSD 磁碟上的 binlog 作為主從同步快取，確保資料同步的可靠性。
使用 SSD 磁碟進行持久化儲存，以保證全量資料的長期儲存。

進一步改進方向：

保留 RedisCache 和 RocksDB Block Cache 作為讀快取。
將 binlog 以多副本方式儲存存入一個日誌型資料庫作為寫快取。
引入一個獨立的 Page Server，負責從日誌型資料庫消費 binlog 然後進行物化，將物化後的資料儲存到 S3，同時充當作為 PikiwiDB（原 Pika）的讀快取。

這一方案可以保證資料的最終一致性，適用於 group 內 slave 節點的極速啟動，對 slot 資料進行快速 rebalance，因為只需重新重放部分 binlog record 即可。

2. 狀態管理

目前的 Operator 僅實現了 Shard 的 Scale Out 功能，尚未完全支援 Scale In。在執行 Scale In 操作時，首先禁用槽位（Slot）的重新平衡（slot rebalance），接著進行槽位的移出（slot move out），然後逐步減少 Shard 的數量，最終再啟用槽位的重新平衡。這個流程確保了在減少 Shard 的過程中不會導致資料不一致，有效管理叢集規模的動態變化。

還需要實現一個獨立的可在多雲環境執行的 etcd manager，以探針方式監控每個 etcd cluster manager，管理一個健康的 etcd 叢集。

3. 可觀測性

將 PikiwiDB（原 Pika）叢集的監控元件 pika-exporter 在 Operator 中進行整合，以實現該元件的高可用性。

4. 資料備份

首先，我們計劃使各個元件能夠獨立配置儲存，以提高系統的靈活性和可定製性。其次，我們著手實現叢集資料備份，以確保資料的安全性和可恢復性。隨後，我們將推動 Operator 實現叢集從備份拉起的功能，從而降低系統維護的複雜性。最後，我們將專注於實現叢集恢復備份的流程，以更加高效地應對潛在的系統故障。

四、結語

KubeBlocks 團隊和 PikiwiDB（原 Pika）社群一起透過基於 KubeBlocks 的 PikiwiDB（原 Pika）雲化探索，我們不僅實現了 PikiwiDB（原 Pika）在雲環境中更高效、便捷的部署和管理，同時為 PikiwiDB（原 Pika）的未來發展提供了新的可能性。

這一深度的探討不僅解決了雲化過程中的難題，也為 PikiwiDB（原 Pika）社群的使用者提供了更好的使用體驗。歡迎試用我們的雲化方案，也誠邀 PikiwiDB（原 Pika）社群的使用者積極參與共建，共同推動 PikiwiDB（原 Pika）在雲端計算時代的發展。

基於 KuBeblocks 的 PikiwiDB(原Pika) 雲化下一站