宏虹將提供您所需的任何支援！
專業的宏虹團隊會第一時間回應，為您提供最佳的服務，解決您的一切問題
實現無感擴展與高可用性
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 延遲基準測試結果