當我們搭建集群的時候,首先要想明白需要解決哪些問題,搞清楚這個之前,想想單節點、單實例、單機有哪些問題?
- 單點故障
- 容量有限
- 可支持的連接有限(性能不足)
- ......
為了解決這些問題,我們需要對服務器進行集群,一變多,具體怎們擴充服務器呢?
這兒引入一個概念,微服務設計原則之一——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軸拆分:基於數據拆分。