虹科干貨丨輕松簡化數(shù)據(jù)庫客戶端工作，除了Proxy還有誰？

引導語（簡介）：隨著業(yè)務拓展，單點redis無法滿足越來越高的性能要求，但使用Redis OSS Cluster和Redis Sentinel來解決起問題太過復雜。此時，就需要Redis Enterprise Proxy來保持數(shù)據(jù)庫操作和維護的簡便性。

朋友圈文案：Redis Enterprise Proxy是什么？如果開發(fā)人員需要拓展業(yè)務、構(gòu)建更復雜的應用程序，那么它將幫助開發(fā)人員輕松地達成這一目標，而不需要編寫很多代碼。

大多數(shù)開發(fā)人員在構(gòu)建應用程序時，一般會從小規(guī)模開始，使用簡單的 Redis 開源（Redis OSS）數(shù)據(jù)庫。一開始，數(shù)據(jù)庫的使用非常簡單，它只有一個節(jié)點，僅僅需要應用程序連接到該端點并開始發(fā)送請求。

而當 Redis 應用程序需要更多特性時，如擴展和高可用性，麻煩就來了。 為此，可以使用Redis OSS Cluster和Redis Sentinel來解決這些問題。不過，這需要開發(fā)人員維護數(shù)據(jù)庫的拓撲結(jié)構(gòu)并處理實際的擴展問題。換言之，你必須編寫更多代碼，而在企業(yè)級應用中，這將很快使應用會變得更為復雜。

Redis Enterprise 借助Proxy擺脫了這些額外的工作，從而解決了這些復雜性問題。無論你是從 Enterprise 直接開始，還是從 Redis OSS 遷移而來，我們設計它的目的就是為了讓應用程序在大規(guī)模運行時，仍然保持數(shù)據(jù)庫操作和維護的簡便性。

一、Proxy 是什么?

Redis Enterprise Proxy 是應用程序與數(shù)據(jù)庫之間的中介實體，其延遲很低，甚至可以忽略不計。它只將數(shù)據(jù)庫端點提供給數(shù)據(jù)庫客戶端， 隱藏Redis Enterprise 集群的內(nèi)部活動。這樣，開發(fā)人員就可以專注于應用程序的數(shù)據(jù)使用情況，而不必擔心數(shù)據(jù)庫拓撲結(jié)構(gòu)的頻繁變化。

Proxy 采用多線程架構(gòu)，可以通過使用更多可用 CPU 內(nèi)核輕松擴展。它通過使用多路復用和流水線設計來應對高流量。當成千上萬的客戶端同時連接到 Redis Enterprise 時，代理會將所有傳入請求整合到一組內(nèi)部管道中，并將它們分發(fā)到相關的數(shù)據(jù)庫分片，使得最終的請求處理速度大大加快，同時實現(xiàn)高吞吐量和低延遲。

圖 1：Redis Enterprise 代理在應用程序和數(shù)據(jù)庫之間進行調(diào)解

二、常見的集群級情況

讓我們來看看導致拓撲變化的幾種常見集群級情況。我們將展示如何將這些變化隱藏在 Proxy 之后，使集群向客戶端提供的數(shù)據(jù)庫端點不變。 從開發(fā)人員的角度來看，這意味著減少了額外的編碼，以及可順利從 Redis OSS 遷移到 Redis Enterprise。

1.擴展

只要數(shù)據(jù)庫分片達到一定（預定義）大小，Redis Enterprise 就能對其進行擴展。擴展是通過啟動一個新的 Redis 實例，并將原始分區(qū)一半的哈希槽移動到新分區(qū)來實現(xiàn)的。這樣，數(shù)據(jù)庫的吞吐量和性能就會呈線性增長。

在 Redis Enterprise 中，有兩種擴展數(shù)據(jù)庫的方法：

• 縱向擴展：在不增加集群節(jié)點的情況下，向數(shù)據(jù)庫添加分片。添加分片需要集群有足夠的容量（內(nèi)存和 CPU）。
• 橫向擴展：在創(chuàng)建新分片之前，向 Redis Enterprise 集群添加一個（或多個）新節(jié)點。常用在集群的現(xiàn)有物理資源不足以擴展數(shù)據(jù)庫時。

2.縱向擴展

下面是一個關于縱向擴展的例子。

圖 2：在 Redis Enterprise 中擴展數(shù)據(jù)庫?？蛻舳死^續(xù)使用相同的數(shù)據(jù)庫端點

圖 2 顯示了將單分片數(shù)據(jù)庫擴展為雙分片數(shù)據(jù)庫的示例。在圖片左側(cè)（擴展前），可以看到包含單分片的單節(jié)點。在圖片右側(cè)（擴展完成后），數(shù)據(jù)庫被重新分片。現(xiàn)在，分片 1 和分片 2 位于同一節(jié)點，各自擁有一半的哈希槽。

那么，擴展是否會改變客戶端連接數(shù)據(jù)庫的方式？答案是“不會”。客戶端會繼續(xù)像以前一樣向相同的數(shù)據(jù)庫端點發(fā)送請求，讓 Proxy 負責將每個請求轉(zhuǎn)發(fā)到相應的分片。

這與 Redis OSS 集群不同，在Redis OSS中，客戶端分別連接到每個分片，因此必須了解集群拓撲結(jié)構(gòu)才能完成擴展。

3.橫向擴展

下面是一個關于橫向擴展的例子。

圖3：使用多Proxy策略時擴展數(shù)據(jù)庫

相反，如果我們在使用多Proxy策略時擴展數(shù)據(jù)庫，會發(fā)生什么情況呢？在這種情況下，我們有多個 Proxy 在同一個端點后面運行。

(在 Redis Enterprise 中，也可以通過使用 OSS Cluster API 的形式擴展數(shù)據(jù)庫。 在這種情況下，每個 Proxy 都有自己的端點）

圖 3 顯示了將一個雙分片數(shù)據(jù)庫擴展到一個四分片數(shù)據(jù)庫。左側(cè)的集群中添加了一個新節(jié)點，其中包含一個仍處于非活動狀態(tài)的 Proxy。擴展完成后，分片 1 和分片 2 位于節(jié)點 1，分片 3 和分片 4 位于節(jié)點 2。這兩個節(jié)點現(xiàn)在都包含啟用的Proxy。

橫向擴展也不會改變客戶端連接數(shù)據(jù)庫的方式，因為這些變化對客戶端來說都是“透明”的，客戶端無需關心集群內(nèi)部的變化。數(shù)據(jù)庫繼續(xù)像以前一樣向相同的數(shù)據(jù)庫端點發(fā)送請求。處理每個請求的 Proxy 會將這些請求轉(zhuǎn)發(fā)給相關的分片。

4.自動故障轉(zhuǎn)移

Redis Enterprise 實現(xiàn)高可用性的一個關鍵在于自動故障轉(zhuǎn)移，它依賴于數(shù)據(jù)復制。當檢測到 Redis Enterprise 集群內(nèi)出現(xiàn)故障時，無論是數(shù)據(jù)庫分片中斷還是整個節(jié)點失效，集群都能在幾秒鐘內(nèi)實現(xiàn)自我修復。
修復過程由集群管理器執(zhí)行，通常會改變集群內(nèi)的數(shù)據(jù)庫拓撲結(jié)構(gòu)。Proxy 會收到通知，并根據(jù)新的拓撲結(jié)構(gòu)進行調(diào)整。

而從數(shù)據(jù)庫客戶端的角度來看，沒有任何變化?？蛻舳藢⒗^續(xù)使用與以前相同的數(shù)據(jù)庫端點，因為拓撲變化是隱藏在代理之后的內(nèi)部變化。

下面我們來看兩個故障轉(zhuǎn)移示例

• 主分片故障轉(zhuǎn)移

下面是個關于主分片故障轉(zhuǎn)移的例子。

圖 4：主分片自動故障轉(zhuǎn)移

圖 4 左側(cè)的主分片位于節(jié)點 1，其副本位于節(jié)點 2。Proxy 會將所有客戶端請求發(fā)送到主分片，主分片會時刻與其副本同步數(shù)據(jù)變化。如果出了問題怎么辦？

如果主分片發(fā)生故障，Redis Enterprise 集群管理器會將副本分片升級為主分片。Proxy 現(xiàn)在會將接收到的請求重定向到新的主分片，讓客戶端照常運行。最后一步是創(chuàng)建新的副本分片（如圖 4 右側(cè)所示）。

• 節(jié)點故障轉(zhuǎn)移

在本例中，整個節(jié)點發(fā)生故障，包括主分片和Proxy。數(shù)據(jù)庫客戶端會斷開連接。

不過，一旦 Redis Enterprise 集群管理器完成故障轉(zhuǎn)移過程，客戶端就會重新連接到與之前相同的數(shù)據(jù)庫端點，并照常進行操作。從開發(fā)人員和操作的角度來看，無需做任何更改，因為群集故障轉(zhuǎn)移機制會將相同的端點分配給不同的代理。

圖 5：自動節(jié)點故障切換，客戶端重新連接到相同的數(shù)據(jù)庫端點

圖 5 展示了節(jié)點 1 出現(xiàn)故障時的故障轉(zhuǎn)移流程。節(jié)點 2 的代理變?yōu)閱⒂脿顟B(tài)，Redis Enterprise 將副本提升為主節(jié)點。數(shù)據(jù)庫現(xiàn)在又可用了，因此客戶可以重新連接，而不會察覺到拓撲結(jié)構(gòu)的變化。集群管理器還會找到一個健康的節(jié)點（節(jié)點 3），Redis Enterprise 會在其中創(chuàng)建一個新的副本分片。

三、用數(shù)據(jù)說話，Proxy到底有多高效？

Proxy 無疑簡化了數(shù)據(jù)庫客戶端的工作，但其實現(xiàn)的速度有多快？為了檢驗它的效率，讓我們來看看一些基準數(shù)據(jù)。

為了對延遲進行基準測試，我們使用了一個單端點 Redis Enterprise Cloud 集群。我們設計了一個包含 20% SET（寫）和 80% GET（讀）命令的常見場景。

我們創(chuàng)建了一個內(nèi)存限制為 5GB 的數(shù)據(jù)庫，并選擇了五個吞吐量目標： 分別為每秒 50K、100K、200K、400K 和 800K 次操作（ops/sec）。對于每種配置，Redis Enterprise Cloud 都會選擇合適的云實例來使用，確保集群以最小的成本獲得足夠的資源。

圖 6：p50 延遲基準測試結(jié)果

圖6的結(jié)果展示了 Redis Enterprise 有多快。在所有目標吞吐量下，該基準測試都能將p50延遲（50%的延遲）保持在亞毫秒級。在某些情況下，它的p99 延遲（99%的延遲）能達到亞毫秒級。

虹科是Redis原廠的中國區(qū)戰(zhàn)略合作伙伴。我們持續(xù)關注各行業(yè)當下急切需求，專注于為企業(yè)解答疑問，制定專屬服務，提供一站式數(shù)據(jù)庫和商業(yè)智能解決方案。了解更多【企業(yè)級數(shù)據(jù)庫解決方案】及【企業(yè)緩存指南】，歡迎前往虹科云科技官網(wǎng)！

聯(lián)系虹科工程師：15528663362

聯(lián)系方式鏈接：https://t.dustess.com/Fc6fpUjg

官網(wǎng)鏈接：https://hongcloudtech.com/