微服務拆分原則之 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 軸拆分: 基於數據拆分。

作者：等不到的口琴

來源：https://www.cnblogs.com/Courage129/p/14344151.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FZBK9X8cGlO0gvJ_GZDigA

猜你喜歡