Redis集羣拆分原則之AKF

當咱們搭建集羣的時候,首先要想明白鬚要解決哪些問題,搞清楚這個以前,想一想單節點、單實例、單機有哪些問題?

• 單點故障
• 容量有限
• 可支持的鏈接有限(性能不足)
• ......

爲了解決這些問題,咱們須要對服務器進行集羣,一變多,具體怎們擴充服務器呢?

這兒引入一個概念,微服務設計原則之一——AKF原則

微服務拆分原則之AKF

首先來看單節點的單點故障這個問題,既然單節點容易掛,那麼就能夠進行復制,一變多,這兒設計到三個概念,主從、主主、主備,也是三種方式,簡單來講,主主至關於多臺服務器同時對外提供讀寫:

主從,主機能夠讀寫,可是通常只對外提供寫,從機對外提供讀:

主備,主機提供讀寫,備機不對外提供服務,當主機掛了的時候,備機經過選舉產生主機對外提供服務。

X軸拆分

能夠看到的是,這幾種拆分一臺機器能夠當作另外一臺機器的鏡像,基本具備全量數據,這種拆分模式就是AKF拆分模式之一:X軸拆分

上圖就是AKF拆分示意圖,爲了解決單點故障,因此弄幾臺全量數據的機器作備份,例如以前說到的主主、主備等,特色是任何兩臺包含的數據是差很少的,一臺能夠當作另外一臺的鏡像。

Y軸拆分

這時候又有新的問題,例如一臺服務器中,可能某些功能被頻繁訪問,涉及到的數據頻繁讀寫,其餘數據基本不怎麼訪問,這時候能夠將這部分數據獨立出來,也就是根據功能、業務繼續拆分服務器,這種拆解就是AFK中的Y軸拆分

特色是Y軸縱向來看不一樣的Redis負責的功能是不一樣的,也就是所包含的數據也是不一樣的,另外僅僅擴展出一個Y軸上的業務服務器,又可能會存在單點問題,因此能夠結合AFK的X軸拆分原則,繼續對剛拆分的Y軸上的點進行X軸拆分。

Z軸拆分

在上面的AFK原則X-Y拆分以後,對服務器顯示作了主從主備複製,而後作了業務拆分,不一樣的Redis負責不一樣的業務請求,這時候還會有一個新的問題,例如對於Y軸上一個Redis,它負責某同樣業務,可是這天這個業務的數據訪問巨大,賊大,那就只好對數據請求進行AFK的Z軸拆分,例如先分析下數據請求的狀況,而後根據訪問來源,分爲北京的、上海的,這樣不一樣的Redis雖然是負責不一樣的數據,可是負責的業務是同樣的。AFK拆分圖示:

AFK總結

X軸拆分:水平復制，就是講單體系統多運行幾個實例，作集羣加負載均衡的模式,主主、主備、主從。

Y軸拆分:基於不一樣的業務拆分

Z軸拆分:基於數據拆分。