本文介紹了 PayPal 開源的新一代高性能分佈式鍵值存儲系統 JunoDB，分析了其設計背景和架構。

1. 引言

JunoDB 是由 PayPal 開發並開源的專有分佈式 KV 存儲，旨在滿足 PayPal 全球支付平台的極端需求，每天處理約 3500 億次請求。JunoDB 設計為高可用性、安全性和可擴展性，保持六個九的可用性（99.9999%），意味着每年停機時間少於 32 秒。作為 PayPal 核心基礎組件，幾乎為所有後端服務，包括用户登錄、風險分析到最終交易處理。

2. 背景與動機

PayPal 決定打造自定義數據庫，是因為現有解決方案（如 Redis）在滿足特定需求方面存在侷限性。Redis 是強大的內存存儲，只受限於內存，但本質上是單線程的，原生無法利用多 CPU 核心。

PayPal 不斷演變的需求要求支持 CPU 密集型功能，如數據加密和其他複雜計算，需要系統只受限於 CPU，而不是內存。因此，JunoDB 從最初原型 —— 一個用於短期內存數據的單線程 C++ 程序 —— 轉變為一個高度併發、多核友好的系統。這一演變包括用 Golang 全面重寫，以及支持持久化存儲和長期數據的轉變。

3. 架構概述

JunoDB 採用三層代理架構，將客户端應用與物理存儲服務器分離，在可擴展性、連接管理和運維效率方面具有顯著優勢。客户端請求首先被路由到無狀態代理層，然後代理層與相應存儲服務器通信以執行操作。

該架構由三個主要組件組成：JunoDB 客户端庫、JunoDB 代理和 JunoDB 存儲服務器。

4. 核心組件

JunoDB 客户端庫

該庫嵌入在客户端應用程序中，提供簡單數據存儲和檢索 API。為促進 PayPal 多樣化技術棧的廣泛採用，該庫已用 Java、Go、C++、Node.js 和 Python 實現。客户端負責與 JunoDB 代理層通信。

JunoDB 代理

代理層是關鍵組件，既無狀態又可橫向擴展，主要職能包括：

• 連接池：保持與所有存儲服務器的持久化連接，隨着應用服務擴展，減少數據庫層的連接開銷。
• 請求路由：使用一致性哈希確定哪個存儲分片應處理某個鍵。代理層會參考分片映射以路由相應請求。
• 配置管理：代理使用 etcd（分佈式鍵值存儲）來存儲和管理分片映射數據，允許對集羣拓撲進行動態更新。

為了防止代理本身成為單點故障，多個代理實例會在負載均衡器後運行。

JunoDB 存儲服務器

這是物理存儲的有狀態層。存儲服務器接受代理的請求並執行 CRUD（創建、讀取、更新、刪除）操作。底層存儲引擎是 RocksDB，這是 Facebook 開發的高性能嵌入式鍵值存儲，採用日誌結構化合並樹（LSM Tree）數據結構，實現了極高的寫入吞吐量，並支持內存存儲和持久化磁盤存儲。

5. 可擴展性方法

JunoDB 設計時在連接層和數據層均實現橫向擴展。

• 連接擴展：隨着應用客户端數量的增加，無狀態代理層可以通過添加更多代理實例來擴展，使 JunoDB 能夠處理大量進站連接而不降低性能。
• 數據擴展：數據被劃分為固定數量的 1024 個分片，基於一致性哈希將鍵映射到分片。算法確保在添加或移除存儲節點時，只需重新映射最小數量的鍵，從而極大簡化了集羣擴展和數據重新分配的工作。

6. 一致性與可用性機制

實現六個九的可用性需要強有力的容錯和數據一致性策略。

• 高可用性：JunoDB 通過積極複製（aggressive replication）實現這一點。存儲節點被組織成多個物理位置或“區域”的邏輯組。節點故障時，系統提供自動且瞬時的故障切換，無需複雜的領導人重選流程或數據重分配。代理檢查連接失效或超時，無縫的向另一個副本重試請求。
• 數據一致性：在數據中心內，JunoDB 採用基於定額的協議（quorum-based protocol）實現同步複製，確保強一致性。要使讀寫操作成功，必須在大多數副本之間達成共識。規則是 Write Quorum (W) + Read Quorum (R) > Number of Replicas (N)。典型的 PayPal 生產環境配置使用 5 個區域（N=5），寫 Quorum 為 3，讀 Quorum 為 3，確保每次讀取始終看到最新提交的寫入數據。跨數據中心複製異步進行，以確保災難恢復而不影響主集羣延遲。

7. 安全特性

作為全球支付處理商的核心組件，安全性是 JunoDB 最重要的設計原則，它提供端到端數據保護：

• 數據傳輸：客户端、代理和存儲服務器之間的所有通信默認採用 TLS 加密保護。
• 靜態數據：磁盤上存儲的所有數據均加密以防止未經授權訪問。
• 密鑰管理：專用密鑰管理模塊負責證書和加密密鑰的生命週期，以便密鑰自動輪換和安全分發。

8. PayPal 使用案例

JunoDB 結合了性能、可擴展性和可用性，使其適用於 PayPal 的多個應用：

• 分佈式緩存：用作高度可靠的緩存，用於存儲頻繁訪問但變化不頻繁的數據，如用户偏好、賬户詳情和 API 響應，支持短期（秒）和長期（天）TTL。
• 冪等性：為防止支付等關鍵操作被重複處理，JunoDB 用於存儲交易 ID。其高可用性確保重試時可以安全的檢查操作是否已處理，避免雙花等錯誤。
• 分佈式計數器：作為中央存儲，用於跟蹤資源使用情況，例如 API 速率限制或用户認證嘗試次數等。
• 延遲橋接：對於像 Oracle 這樣以雙主配置運行的遺留數據庫系統，地理複製可能較慢。JunoDB 作為快速複製中介，將數據同時寫入 Oracle 和 JunoDB。故障發生時，應用程序可以讀取來自二級數據中心 JunoDB 的最新數據，從而彌補主數據庫的複製延遲。

9. 開源之旅

2023 年，PayPal 以寬鬆的 Apache 2.0 許可證，在 GitHub 上將 JunoDB 作為開源項目發佈。目標是與更廣泛的社區分享技術，促進進一步發展。服務器採用 Golang 編寫，利用該語言對併發的強力支持。在發佈時，項目路線圖包括為 Kubernetes 開發 JunoDB operator 及額外客户端庫的計劃。

10. 結論

JunoDB 是目標導向設計工程的有力證明。通過識別現成解決方案無法滿足的具體需求 —— 即高併發、高 CPU 負載且可大規模擴展的鍵值存儲 —— PayPal 打造了支撐其全球運營的基礎設施。其架構在可擴展性、高可用性、強一致性和安全性之間取得了深思熟慮的平衡，為構建大規模分佈式系統的工程師提供了寶貴的案例研究。

你好，我是俞凡，在Motorola做過研發，現在在Mavenir做技術工作，對通信、網絡、後端架構、雲原生、DevOps、CICD、區塊鏈、AI等技術始終保持着濃厚的興趣，平時喜歡閲讀、思考，相信持續學習、終身成長，歡迎一起交流學習。為了方便大家以後能第一時間看到文章，請朋友們關注公眾號"DeepNoMind"，並設個星標吧，如果能一鍵三連(轉發、點贊、在看)，則能給我帶來更多的支持和動力，激勵我持續寫下去，和大家共同成長進步！

本文由mdnice多平台發佈