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

引導(dǎo)語(yǔ)（簡(jiǎn)介）：隨著業(yè)務(wù)拓展，單點(diǎn)redis無(wú)法滿足越來(lái)越高的性能要求，但使用Redis OSS Cluster和Redis Sentinel來(lái)解決起問(wèn)題太過(guò)復(fù)雜。此時(shí)，就需要Redis Enterprise Proxy來(lái)保持數(shù)據(jù)庫(kù)操作和維護(hù)的簡(jiǎn)便性。

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

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

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

Redis Enterprise 借助Proxy擺脫了這些額外的工作，從而解決了這些復(fù)雜性問(wèn)題。無(wú)論你是從 Enterprise 直接開(kāi)始，還是從 Redis OSS 遷移而來(lái)，我們?cè)O(shè)計(jì)它的目的就是為了讓?xiě)?yīng)用程序在大規(guī)模運(yùn)行時(shí)，仍然保持?jǐn)?shù)據(jù)庫(kù)操作和維護(hù)的簡(jiǎn)便性。

一、Proxy 是什么?

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

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

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

二、常見(jiàn)的集群級(jí)情況

讓我們來(lái)看看導(dǎo)致拓?fù)渥兓膸追N常見(jiàn)集群級(jí)情況。我們將展示如何將這些變化隱藏在 Proxy 之后，使集群向客戶端提供的數(shù)據(jù)庫(kù)端點(diǎn)不變。 從開(kāi)發(fā)人員的角度來(lái)看，這意味著減少了額外的編碼，以及可順利從 Redis OSS 遷移到 Redis Enterprise。

1.擴(kuò)展

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

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

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

2.縱向擴(kuò)展

下面是一個(gè)關(guān)于縱向擴(kuò)展的例子。

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

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

那么，擴(kuò)展是否會(huì)改變客戶端連接數(shù)據(jù)庫(kù)的方式？答案是“不會(huì)”?？蛻舳藭?huì)繼續(xù)像以前一樣向相同的數(shù)據(jù)庫(kù)端點(diǎn)發(fā)送請(qǐng)求，讓 Proxy 負(fù)責(zé)將每個(gè)請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的分片。

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

3.橫向擴(kuò)展

下面是一個(gè)關(guān)于橫向擴(kuò)展的例子。

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

相反，如果我們?cè)谑褂枚郟roxy策略時(shí)擴(kuò)展數(shù)據(jù)庫(kù)，會(huì)發(fā)生什么情況呢？在這種情況下，我們有多個(gè) Proxy 在同一個(gè)端點(diǎn)后面運(yùn)行。

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

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

橫向擴(kuò)展也不會(huì)改變客戶端連接數(shù)據(jù)庫(kù)的方式，因?yàn)檫@些變化對(duì)客戶端來(lái)說(shuō)都是“透明”的，客戶端無(wú)需關(guān)心集群內(nèi)部的變化。數(shù)據(jù)庫(kù)繼續(xù)像以前一樣向相同的數(shù)據(jù)庫(kù)端點(diǎn)發(fā)送請(qǐng)求。處理每個(gè)請(qǐng)求的 Proxy 會(huì)將這些請(qǐng)求轉(zhuǎn)發(fā)給相關(guān)的分片。

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

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

而從數(shù)據(jù)庫(kù)客戶端的角度來(lái)看，沒(méi)有任何變化?？蛻舳藢⒗^續(xù)使用與以前相同的數(shù)據(jù)庫(kù)端點(diǎn)，因?yàn)橥負(fù)渥兓请[藏在代理之后的內(nèi)部變化。

下面我們來(lái)看兩個(gè)故障轉(zhuǎn)移示例

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

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

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

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

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

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

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

不過(guò)，一旦 Redis Enterprise 集群管理器完成故障轉(zhuǎn)移過(guò)程，客戶端就會(huì)重新連接到與之前相同的數(shù)據(jù)庫(kù)端點(diǎn)，并照常進(jìn)行操作。從開(kāi)發(fā)人員和操作的角度來(lái)看，無(wú)需做任何更改，因?yàn)槿杭收限D(zhuǎn)移機(jī)制會(huì)將相同的端點(diǎn)分配給不同的代理。

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

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

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

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

為了對(duì)延遲進(jìn)行基準(zhǔn)測(cè)試，我們使用了一個(gè)單端點(diǎn) Redis Enterprise Cloud 集群。我們?cè)O(shè)計(jì)了一個(gè)包含 20% SET（寫(xiě)）和 80% GET（讀）命令的常見(jiàn)場(chǎng)景。

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

圖 6：p50 延遲基準(zhǔn)測(cè)試結(jié)果

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

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

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

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

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