1 背景

互聯網場景下，我們經常會面臨一個產品流量從初創時期的小流量到全盛大流量的過程。
這時候，原本的架構設計就顯得很不合理，變成你追求服務穩定性阻礙。
然而這一切並不一定是你的架構能力的問題，而是在小流量場景下，不能過高的去評估容量和架構冗餘性，避免造成不必要的資源和維護人力的浪費。
能做的是爲以後的架構演進提供可擴展性準備，讓原本強依賴數據存儲層的風險可以實現逐層降級。

2 強依賴降級過程

2.1 第一階：簡單流量，讀寫不分離

如果你的業務剛上線，服務流量很小，那你大概率數據服務會僅部署一個實例，讀寫也會匯聚在一些。結構如下：

這樣做的好處是：

• 小流量場景下資源利用率高

• 一致性高，不會出現讀寫順序和一致性問題

這樣做的壞處是：

• 讀寫互相影響，一旦出現故障，整體不可用

2.2 第二階：流量上漲，讀大於寫，讀寫分離

大廠內部的評估法則通常流量達到一定規模，並且讀寫比不低於 8:2，否則讀寫分離的價值不大。結構如下：

讀寫分離這種數據庫架構策略，將數據庫的讀和寫操作分散到不同的數據庫服務器上。這種策略有助於提高數據庫的併發處理能力和整體性能。

讀寫分離的基本思想是將數據庫的讀操作和寫操作分開處理，通常使用一個主數據庫（Master）來處理寫操作（如 INSERT、UPDATE、DELETE 等），而使用多個從數據庫（Slave）來處理讀操作（如 SELECT 等）。主數據庫會將其更改實時同步到一個或多個從數據庫中，確保數據的一致性。

它有如下優勢：

• 負載均衡：分發讀操作到多個從數據庫服務器，以提高併發處理能力和負載均衡。

• 監控和故障轉移：檢測數據庫服務器的健康狀況，並在主數據庫出現故障時自動切換到從數據庫。

也存在一些挑戰和限制：

• 主從同步可能會引入延遲，導致從數據版本差異

• 讀寫分離也可能增加數據一致性和故障恢復的複雜性

2.3 第三階：多域流量和穩定性要求高，兩地三中心

“兩地三中心” 是指本地和異地分別建立三個中心，包括本地生產中心、同城災備中心和異地災備中心。這種架構旨在確保業務的高可用性和數據的安全性，以應對各種自然災害或人爲因素導致的業務中斷。

從圖中『核心指標』可以看出，它主要提高了可用性，即使在大規模流量場景下，能夠保證系統足夠健壯。
詳細可以參考筆者這一篇《高可用架構，去中心化有多重要？》

2.4 第四階：使用緩存進行風險降級

緩存的目的主要是兜底，避免持久化數據層出現故障時候的完全不可用。
同時能提高性能和可用性，畢竟高速緩存和磁盤的效率不可同日而語，多了一層保障，可用性也大幅提升。
詳細可以參考筆者這邊《深刻理解高性能 Redis 的本質》。

2.5 第五階：去中心化，本地緩存提升可用性

互聯網性能演進經常會聽到這樣一句話：把數據放在離用戶最近的地方，即安全又快捷。
無論讀取數據庫還是讀取緩存服務，畢竟是跨節點的，那就存在風險，網絡抖動，機房故障都有可能成爲故障誘因。
去中心化的本質是在所有依賴項都無法正常運轉之後，服務依然獨立可用。
詳細可以參考筆者這一篇《高可用架構，去中心化有多重要？》

這邊的做法就是在本地緩存一份剛性數據，允許一定的延遲，但是需要保證服務不被掛起，短時間內（一般 4 小時爲判斷標準）服務有依然可用。如下圖：

3 總結

本文介紹了互聯網場景下高流量的數據強依賴的降級演進過程。主要核心點如下：

• 讀寫分離保證數據存儲單點故障的恢復，如：Master 故障，Slave 切換成 Master；Slave 故障，讀寫匯聚到 Master

• 兩地三中心提高可用性，應對地域級風險

• 緩存服務提高性能和可用性，爲數據中心故障做兜底

• 本地緩存實現去中心化，進一步提高可用性，依賴項故障依然能保證服務獨立可用

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