溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Redis集群架構(gòu)及對比的示例

發(fā)布時間:2021-03-12 11:41:50 來源:億速云 閱讀:316 作者:小新 欄目:關(guān)系型數(shù)據(jù)庫

小編給大家分享一下Redis集群架構(gòu)及對比的示例,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!

1、Redis3.0

Redis集群架構(gòu)及對比的示例

·        優(yōu)點(diǎn)

a. 無中心節(jié)點(diǎn)

b. 數(shù)據(jù)按照 slot 存儲分布在多個 Redis 實(shí)例上

c. 平滑的進(jìn)行擴(kuò)容/縮容節(jié)點(diǎn)

d. 自動故障轉(zhuǎn)移(節(jié)點(diǎn)之間通過 Gossip 協(xié)議交換狀態(tài)信息,進(jìn)行投票機(jī)制完成 Slave 到 Master  角色的提升)

e. 降低運(yùn)維成本,提高了系統(tǒng)的可擴(kuò)展性和高可用性

(推薦(免費(fèi)):redis

·        缺點(diǎn)

a. 嚴(yán)重依賴外部 Redis-Trib

b. 缺乏監(jiān)控管理

c. 需要依賴 Smart Client(連接維護(hù), 緩存路由表, MultiOp 和 Pipeline  支持)

d. Failover  節(jié)點(diǎn)的檢測過慢,不如“中心節(jié)點(diǎn) ZooKeeper”及時

e. Gossip  消息的開銷

f. 無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)

g. Slave“冷備”,不能緩解讀壓力

2、Proxy +Redis Cluster

Redis集群架構(gòu)及對比的示例

· 優(yōu)點(diǎn)

Smart Client:

a. 相比于使用代理,減少了一層網(wǎng)絡(luò)傳輸?shù)南?,效率較高;

b. 不依賴于第三方中間件,實(shí)現(xiàn)方法和代碼自己掌控,可隨時調(diào)整。

Proxy:

a. 提供一套 HTTP Restful 接口,隔離底層存儲。對客戶端完全透明,跨語言調(diào)用。

b. 升級維護(hù)較為容易,維護(hù) Redis Cluster,只需要平滑升級 Proxy。

c. 層次化存儲,底層存儲做冷熱異構(gòu)存儲。

d. 權(quán)限控制,Proxy 可以通過秘鑰控制白名單,把一些不合法的請求都過濾掉。并且也可以控制用戶請求的超大 Value 進(jìn)行控制和過濾。

e. 安全性,可以屏蔽掉一些危險命令,比如 Keys、Save、Flush All 等。

f. 容量控制,根據(jù)不同用戶容量申請進(jìn)行容量限制。

g. 資源邏輯隔離,根據(jù)不同用戶的 Key 加上前綴,來進(jìn)行資源隔離。

h. 監(jiān)控埋點(diǎn),對于不同的接口進(jìn)行埋點(diǎn)監(jiān)控等信息。

·  缺點(diǎn)

Smart Client:

a. 客戶端的不成熟,影響應(yīng)用的穩(wěn)定性,提高開發(fā)難度。

b. MultiOp  和 Pipeline  支持有限。

c. 連接維護(hù),Smart 客戶端對連接到集群中每個結(jié)點(diǎn) Socket 的維護(hù)。

Proxy:

a. 代理層多了一次轉(zhuǎn)發(fā),性能有所損耗。

b.進(jìn)行擴(kuò)容/縮容時候?qū)\(yùn)維要求較高,而且難以做到平滑的擴(kuò)縮容

3、技術(shù)選型

redis官方文檔中有如下這段話:

The redis-cli cluster support is very basic so it alwaysuses the fact that Redis Cluster nodes are able to redirect a client to theright node. A serious client is able to do better than that, and cache the map betweenhash slots and nodes addresses, to directly use the right connection to theright node. The map is refreshed only when something changed in the clusterconfiguration, for example after a failover or after the system administratorchanged the cluster layout by adding or removing nodes.

大意就是目前redis cluster官方客戶端功能簡陋,依賴于redis節(jié)點(diǎn)重定向去到集群中找到數(shù)據(jù)所在的redis實(shí)例。需要有一個更完善的客戶端,能夠?qū)崿F(xiàn)一致性hash,failover和集群管理功能。因此使用官方的redis cluster客戶端不是一個明智的選擇,本文提供3種方案供大家參考,如果有不合理的地方,歡迎大家與我共同探討。

方案 1 使用nginx開發(fā)(OpenResty方式)

原因如下:

a. 單Master多Work模式,每個Work跟Redis一樣都是單進(jìn)程單線程模式,并且都是基于Epoll事件驅(qū)動的模式。

b. Nginx采用了異步非阻塞的方式來處理請求,高效的異步框架。

c. 內(nèi)存占用少,有自己的一套內(nèi)存池管理方式。將大量小內(nèi)存的申請聚集到一塊,能夠比Malloc更快。減少內(nèi)存碎片,防止內(nèi)存泄漏。減少內(nèi)存管理復(fù)雜度。

d. 為了提高 Nginx 的訪問速度,Nginx 使用了自己的一套連接池。

e. 最重要的是支持自定義模塊開發(fā)。

f. 業(yè)界內(nèi),對于Nginx,Redis的口碑可稱得上兩大神器。性能都很好。

方案 2 codis(豌豆莢采用的基于代理的redis集群方案)

參考codis官方文檔https://github.com/CodisLabs/codis

Codis是一整套緩存解決方案,包含高可用、數(shù)據(jù)分片、監(jiān)控、動態(tài)擴(kuò)態(tài) etc.。

走的是 Apps->代理->rediscluster,一定規(guī)模后基本都采用這種方式。

方案3 自己獨(dú)立開發(fā)redis智能客戶端

主要實(shí)現(xiàn)redis slots管理,failover,一致性hash功能。

4、Redis 3.0集群

Redis 3.0集群采用了P2P的模式,完全去中心化。Redis把所有的Key分成了16384個slot,每個Redis實(shí)例負(fù)責(zé)其中一部分slot。集群中的所有信息(節(jié)點(diǎn)、端口、slot等),都通過節(jié)點(diǎn)之間定期的數(shù)據(jù)交換而更新。

Redis客戶端在任意一個Redis實(shí)例發(fā)出請求,如果所需數(shù)據(jù)不在該實(shí)例中,通過重定向命令引導(dǎo)客戶端訪問所需的實(shí)例。

Redis 3.0集群的工作流程如下圖所示。

Redis集群架構(gòu)及對比的示例

Redis集群內(nèi)的機(jī)器定期交換數(shù)據(jù),工作流程如下:

(1) Redis客戶端在Redis2實(shí)例上訪問某個數(shù)據(jù);

(2)在Redis2內(nèi)發(fā)現(xiàn)這個數(shù)據(jù)是在Redis3這個實(shí)例中,給Redis客戶端發(fā)送一個重定向的命令;

(3) Redis客戶端收到重定向命令后,訪問Redis3實(shí)例獲取所需的數(shù)據(jù)。

Redis 3.0的集群方案有以下兩個問題:

1)       一個Redis實(shí)例具備了“數(shù)據(jù)存儲”和“路由重定向”,完全去中心化的設(shè)計。這帶來的好處是部署非常簡單,直接部署Redis就行,不像Codis有那么多的組件和依賴。但帶來的問題是很難對業(yè)務(wù)進(jìn)行無痛的升級,若哪天Redis集群出了什么嚴(yán)重的Bug,就只能回滾整個Redis集群。

2)       對協(xié)議進(jìn)行了較大的修改,對應(yīng)的Redis客戶端也需要升級。升級Redis客戶端后誰能確保沒有Bug?而且對于線上已經(jīng)大規(guī)模運(yùn)行的業(yè)務(wù),升級代碼中的Redis客戶端也是一個很麻煩的事情。

5、Redis4.0

Redis集群架構(gòu)及對比的示例

(1)所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬;

(2)節(jié)點(diǎn)的Fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測失效時才生效;

(3)客戶端與redis節(jié)點(diǎn)直連,不需要中間proxy層。客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個可用節(jié)點(diǎn)即可;

(4)redis-cluster把所有的物理節(jié)點(diǎn)映射到[0-16383]slot(插槽)上,cluster 負(fù)責(zé)維護(hù)node<->slot<->value。

以上是“Redis集群架構(gòu)及對比的示例”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道!

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI