Honghong will provide you with any support you need!
Our professional Honghong team will be the first to respond and provide you with the best service to solve all your problems.
實現無感擴展與高可用性
Redis 企業版集群的幕後，發生了許多複雜的操作。而Proxy 則屏蔽了所有這些活動，讓資料庫客戶端無需感知。
大多數開發者在建立應用程式時都會從小規模開始，通常會選擇簡單的Redis 開源版（Redis OSS）資料庫，即使他們知道未來軟體會成為更複雜系統的一部分。起初，使用資料庫非常簡單：應用程式連接到一個端點，並開始發送請求，僅此而已。
真正的挑戰出現在應用程式需要擴展和高可用性時。為此，可以使用Redis OSS Cluster 和Redis Sentinel。但這樣一來，開發者就需要維護資料庫拓撲結構，並處理擴充的具體實作——換句話說，需要寫更多程式碼。在企業級應用中，這種複雜性會迅速升級。
Redis 企業版透過消除額外的工作，解決了這些複雜性問題。無論是直接採用企業級解決方案，還是從Redis OSS 遷移而來，我們的設計確保了其能夠在大規模場景下高效運行，同時讓應用程式使用資料庫依然保持簡單。
無感代理，高效擴展
Proxy 是Redis 企業版一個幾乎無延遲的元件，它在應用程式與資料庫之間充當中介。它向資料庫客戶端暴露資料庫端點，同時屏蔽Redis 企業版叢集在後台執行的各種操作。這讓開發者可以專注於資料的使用，而無需擔心資料庫拓撲的頻繁變化。
此代理程式採用多執行緒架構，可以透過利用更多可用的CPU 核心來輕鬆擴展。它利用多路復用（multiplexing）和流水線（pipelining）機制來處理高並發流量。當數千個用戶端同時連接到Redis 企業版時，代理商會將所有傳入請求整合到一組內部管線中，並將它們分發到對應的資料庫分片。最終，這種方式能夠大幅提升請求處理速度，實現高吞吐量和低延遲。
圖1：Redis Enterprise Proxy 作為應用與資料庫之間的中介
常見場景分析
那麼，這些技術在實際操作中意味著什麼？讓我們來看幾個常見的叢集層級場景，這些場景會導致拓撲結構發生變化。我們將展示這些變化如何在Redis Enterprise Proxy 的背後保持透明，並始終向使用者揭露相同的資料庫端點。從開發者的角度來看——也就是你，意味著更少的程式設計工作和從Redis OSS 到Redis 企業版的平滑遷移。
擴充
當資料庫分片達到預定大小時，Redis 企業版可以進行擴充。擴充功能透過啟動新的Redis 實例，並將原始分片的一半哈希槽移至新分片來實現。這使得資料庫的吞吐量和效能線性成長。
在Redis 企業版中，擴展資料庫有兩種方式：
- 橫向擴展（Scaling up）：在不加入節點到叢集的情況下增加分片。當叢集有足夠的容量（記憶體和CPU）時，可以進行這種擴展。
縱向擴充（Scaling out）：在建立新的分片之前，先在Redis 企業版叢集中新增一個或多個新節點。這發生在叢集的現有實體資源不足以支撐資料庫擴展時。
橫向擴展
下圖顯示了一個單分片資料庫擴展為雙分片資料庫的範例。在左側（擴充前），可以看到一個包含單一分片的節點。右側（擴充完成後），資料庫已重新分片，現在Shard 1 和Shard 2 位於同一個節點，每個分片持有一半的哈希槽。
橫向擴展是否會改變客戶端連接資料庫的方式？不會。客戶端仍然連接到相同的資料庫端點，代理負責將每個請求轉送到對應的分片。值得注意的是，這與Redis OSS 叢集不同，在Redis OSS 中，客戶端需要分別連接到每個分片，並且必須了解叢集拓撲結構。
圖2：在Redis 企業版中擴展資料庫。客戶端繼續使用相同的資料庫端點
縱向擴展
與橫向擴展不同，在使用多代理（multi-proxy）策略進行縱向擴展時，多個代理會在同一個端點後運行。 （需要注意的是，在Redis 企業版中，也可以使用OSS Cluster API 進行縱向擴充。但在這種情況下，每個代理程式都會擁有自己的端點。）
下圖展示了一個資料庫從雙分片擴展為四分片的過程。在左側（擴展前），一個新的節點被加入到叢集中，其中包含一個尚未啟動的代理程式。在擴展完成後，Shard 1 和Shard 2 仍位於Node 1，而Shard 3 和Shard 4 則分配到Node 2，並且兩個節點都運行了活躍的代理。
然而，縱向擴展不會改變客戶端的連接方式，因為這些變化對客戶端是透明的。客戶端依舊使用相同的資料庫端點，代理程式會自動將請求轉送到正確的分片進行處理。
圖3：使用多代理策略進行縱向擴展，客戶端繼續使用相同的資料庫端點
自動故障轉移
Redis 企業版具備自動故障轉移機制，基於資料複製確保高可用性。當叢集偵測到故障（如資料庫分片宕機或整個節點失效），它可以在幾秒鐘內完成自我修復。
這個修復過程由叢集管理器負責，通常涉及資料庫拓撲的調整。代理會收到通知，並自動適配新的拓撲結構，但對客戶端來說，一切保持不變，它們仍然連接到同一個資料庫端點。
以下是兩種典型的故障轉移場景：
主分片故障轉移
在下圖左側，Node 1 運行主分片，Node 2 運行其副本。代理會將所有請求傳送到主分片，而主分片會持續同步資料到副本。
如果主分片發生故障，Redis 企業版叢集管理器會自動將副本分片提升為新的主分片，代理程式隨之調整，所有用戶端請求都會被重新導向到新的主分片。最後，系統會在另一台健康的節點上建立新的副本分片，以恢復資料冗餘
圖4：主分片的自動故障轉移
節點故障轉移
如果整個Node 1 宕機，不僅主分片失效，代理程式也會隨之失去連接，導致資料庫用戶端短暫斷開。一旦Redis 企業版完成故障轉移，客戶端仍然可以使用相同的資料庫端點重新連接，繼續正常運作。對於開發者和維運人員而言，無需做任何額外調整，因為叢集故障轉移機制會自動將相同的端點指向新的代理程式。
下圖展示了Node 1 失效時的故障轉移過程。 Node 2 的代理人被激活，Redis 企業版將副本分片提升為主分片。資料庫復原可用，客戶端無需感知拓撲變更即可重新連線。叢集管理器同時在Node 3 建立新的副本分片。
圖5：自動節點故障轉移，客戶端仍連接相同的資料庫端點。
毫秒響應，Redis 企業版速度實測
Redis Enterprise Proxy 大大簡化了資料庫用戶端的使用，但它的反應速度如何？讓我們來看一些基準測試數據。
為了測試延遲，我們使用了一個單端點的Redis Enterprise Cloud 集群，並執行了一個常見的場景，其中包含20% 的SET（寫入）命令和80% 的GET（讀取）命令。
測試中，我們建立了一個5GB 記憶體限制的資料庫，並設定了五個吞吐目標：50K、100K、200K、400K 和800K 次操作/秒（ops/sec）。 Redis Enterprise Cloud 會自動選擇適當的雲端實例，以確保叢集在盡可能低的成本下擁有足夠的資源。
測試結果顯示，Redis Enterprise 的反應速度極快。在所有目標吞吐量下，中位數（p50）延遲均維持在毫秒級以內，某些情況下，99 分位（p99）延遲也能達到毫秒以下。
下圖展示了對等複製的運作機制：
圖6：p50 延遲基準測試結果
Resources
Technical Articles
Data Encryption / Data Security
Honghong Shares｜ONEKEY 2025 Global Survey Report: Latest Requirements of the EU's Network Firmware Act, Corporate Compliance Gaps and Recommendations for Action
Read More » November 18, 2025
Data Encryption / Data Security
Honghong Case] Swisscom implements ONEKEY automated security analytics platform and successfully saves CHF 370,000 per year!
Read More » October 16, 2025
Redis
June 20, 2025