作者：等不到的口琴
鏈接：https://www.cnblogs.com/Courage129/p/14344151.html
當我們搭建集群的時候,首先要想明白需要解決哪些問題,搞清楚這個之前,想想單節點、單實體、單機有哪些問題?
- 單點故障
- 容量有限
- 可支持的連接有限(性能不足)
- ......
為了解決這些問題,我們需要對服務器進行集群,一變多,具體怎們擴充服務器呢?
這兒引入一個概念,微服務設計原則之一——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軸拆分:基于資料拆分，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.Spring Boot 2.6 正式發布，一大波新特性，，
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/415216.html
標籤：Java
上一篇：訊息推送介面設計（內含原始碼）
下一篇：聊聊dubbo協議2