一. 問題&分析

在讀多寫少的互聯(lián)網(wǎng)業(yè)務(wù)場景，往往“讀”性能會成為第一個瓶頸。

隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)庫負載越來越高，逐漸成為系統(tǒng)的瓶頸。面對“讀”性能瓶頸，大致有以下幾種解題思路：

1. 提升 DB 配置從而獲取更高的性能。使用更 NX 的機器，升級 DB 的 CPU、內(nèi)存、磁盤等；
2. 使用更多的 DB 來分擔讀壓力。對 DB 進行“拆分”，一個 DB 實例負責數(shù)據(jù)寫入，一組 DB 實例負責數(shù)據(jù)查詢，也就是常說的讀寫分離；
3. 將 讀 壓力轉(zhuǎn)移到其他存儲引擎。比如引入讀性能更高的 Cache，讓 Cache 擋在 DB 前面，降低落到 DB 上的請求量；

上面三種方案各具千秋，但性價比最高的仍舊是“讀寫分離方案”：

1. 方案一，升級硬件資源，簡單粗暴，主要是金錢上的考量；另外，硬件是存在天花板的，金錢不能解決一切問題；
2. 方案三，緩存是提升讀性能的一大殺器，追求性能的同時需要做很多事，比如調(diào)整邏輯代碼、進行一致性保障、增加運維成本等，同時也為系統(tǒng)引入更多的復雜性。落地效果非常不錯。但有時，殺雞焉用牛刀？
3. 方案二，中規(guī)中矩介于兩者之間，無需過量的金錢投入，也無需過早的引入太多復雜性

二. 讀寫分離

以數(shù)據(jù)庫部署架構(gòu)為基礎(chǔ)，對數(shù)據(jù)操作進行分離，主節(jié)點主要處理寫請求，從節(jié)點主要處理讀請求。

通過引入多個副本來分散讀請求，從而實現(xiàn) 讀請求 的水平擴展。主副本 與 從副本 間的數(shù)據(jù)一致就是通過 “復制” 來完成。

讀寫分離架構(gòu)有幾個非常重要的概念：

1. 主副本。也稱主節(jié)點，可以接受 讀&寫請求；
2. 從副本。也稱從節(jié)點，只能處理 讀請求；
3. 復制。主副本 與 從副本 間 基于“復制”技術(shù)實現(xiàn)數(shù)據(jù)同步；
4. 路由?；诼酚梢?guī)則將請求分發(fā)至整個集群（主副本 + 從副本）

以最常見的MySQL主從架構(gòu)為例：

通過擴展 Slave 可以實現(xiàn) 讀請求 的水平擴展，核心流程如下：

1. 應用將寫請求路由到 Master 節(jié)點；
2. Master 節(jié)點完成寫入后（事務(wù)提交），將變更寫入到 Binlog；
3. Slave 節(jié)點從 Master 節(jié)點獲取 Binlog，并執(zhí)行變更（涉及中繼日志和并發(fā)復制），保持與 Master 數(shù)據(jù)一致；
4. 應用將讀請求路由到 Slave 節(jié)點，從 Slave 中獲取數(shù)據(jù)；

備注：Slave 過多會加重 Master 的壓力，可通過多級復制或分區(qū)進行解決。

讀寫分離架構(gòu)可以方便的對讀請求進行擴展，看似美好，但需要解決兩個問題：

1. 數(shù)據(jù)同步。如何保障主從副本間的數(shù)據(jù)一致性，通常情況下由存儲引擎的“復制”機制來保障；
2. 請求路由。何時操作主副本，何時操作從副本，如何在多個副本間做負載均衡？

1、復制模式

復制模式主要解決數(shù)據(jù)同步問題。通常比想象中的復雜，在此只對 單主復制 進行介紹，對于多主復制，由于過于復雜，并不在討論范圍。

（1）同步復制

同步復制架構(gòu)如圖所示：

核心流程：

1. 主節(jié)點處理完請求后，將復制信息同步到所有節(jié)點；
2. 待所有節(jié)點返回后，再向用戶返回最終結(jié)果；

特點：

1. 優(yōu)點

1. 強一致性保障，應用寫入成功后，從節(jié)點與主節(jié)點間就達成了一致，不存在數(shù)據(jù)延時問題

2. 缺點
3. 影響寫入性能。寫性能 = Master + Max（Slave）
4. 影響可用性。某個 Slave 異常，直接影響寫入，導致寫入流程被中斷

常見應用場景：

1. 在實際開發(fā)中，該方案很少使用，特別是在 CAP 最終一致性思想的影響下
2. TiDB 等 NewSQL 內(nèi)部通過一致性協(xié)議保障 強一致，基于 NRW 理論保障可用性，這塊非常復雜，不在討論范圍

（2）異步復制

異步復制架構(gòu)如下：

核心流程：

1. 主節(jié)點處理完請求后，直接返回處理結(jié)果；
2. 從節(jié)點通過異步方式從主節(jié)點獲取信息；

特點

1. 優(yōu)點：寫入性能好
2. 缺點：存在數(shù)據(jù)丟失風險

應用場景

1. 數(shù)據(jù)安全性要求低，性能要求高的場景，如 日志記錄 等
2. 極端情況下的“飲鴆止渴”，如 秒殺、大促場景

（3）半同步復制

半同步復制是同步復制和異步復制的結(jié)合體，架構(gòu)如下：

核心流程

1. 主節(jié)點處理完請求后，對部分節(jié)點進行同步復制，等待其復制完成后，在向應用返回最終的處理結(jié)果；
2. 其他剩余節(jié)點進行異步復制

特點

1. 在性能和一致性間做平衡

應用場景

1. 滿足大多數(shù)業(yè)務(wù)場景。

2、路由模式

路由模式，主要決定請求如何分發(fā)到眾多的數(shù)據(jù)庫節(jié)點。

（1）應用路由

在應用層使用代碼對請求進行分發(fā)，整體架構(gòu)如下：

核心流程：

1. 為每個數(shù)據(jù)庫節(jié)點構(gòu)建一個DataSource，結(jié)合 ORM 框架，構(gòu)建不同的 DAO
2. 應用代碼根據(jù)業(yè)務(wù)場景，調(diào)用不同的 DAO 實現(xiàn)，完成讀寫操作
3. 多個從節(jié)點 DataSource 可以封裝為 一個聚合 DAO，內(nèi)嵌負載均衡算法，在不同的 從庫 間進行路由

特點：

1. 優(yōu)點：簡單，使用編碼實現(xiàn)，掌控力最強
2. 缺點：對系統(tǒng)存在極大的侵入性，需要修改大量的邏輯代碼

場景：

1. 存在于老的項目或需要極致掌控力的場景

（2）智能數(shù)據(jù)源

將多個 DataSource 封裝為一個具有路由功能的 SmartDataSource，整體架構(gòu)如下：

核心設(shè)計如下：

1. 每一個數(shù)據(jù)節(jié)點對應一個 DataSource
2. 將多個 DataSource 封裝為一個 SmartDataSource
3. SmartDataSource 自動解析 SQL，根據(jù) SQL 類型自動完成請求路由
4. 應用程序僅于 SmartDataSource 進行通信

特點：

1. 優(yōu)點：對程序沒有侵入性，無需調(diào)整代碼，只需替換底層 DataSource 即可
2. 缺點：集群情況下，需要配置中心進行統(tǒng)一協(xié)調(diào)

場景：

1. 特別使用于高性能場景

（3）Proxy 路由

將 SmartDataSource 核心功能抽取到單獨的服務(wù)，整體架構(gòu)如下：

核心設(shè)計：

1. 將 SmartDataSource 的職能抽取到單獨的服務(wù)
2. 向下管理多個數(shù)據(jù)庫節(jié)點
3. 向上暴露標準的 jdbc 接口，供應用程序使用

特點：

1. 優(yōu)點。便于管理，所有的管理動作全部收口到 Proxy 層；
2. 缺點。增加一層網(wǎng)絡(luò)開銷，對性能有一定的影響；

場景：

1. 使用于管理場景

通常情況下，會在配置中心的基礎(chǔ)上，綜合使用智能路由和Proxy路由兩種模式：

智能路由。用于應用程序，追求極致的性能；

Proxy路由。用于數(shù)據(jù)庫管理，追求管理的便利性；

配置中心。為智能路由和Proxy路由提供統(tǒng)一的配置信息。

三、延時挑戰(zhàn)

應用程序集成讀寫分離后，最主要的挑戰(zhàn)便是：復制延時。所以，在系統(tǒng)設(shè)計時，需要對特定場景進行特殊處理。

1、更新場景，強制切主

對于更新場景，為了避免 主從延時導致的 寫覆蓋問題，通常使用強制切主策略。

寫覆蓋的根源，見下圖：

由于存在主從延時，所加載的 聚合根 不一定是最新的數(shù)據(jù)，因此，后續(xù)的修改 和 保存，都是在過期數(shù)據(jù)上執(zhí)行，導致寫丟失。

備注：樂觀鎖保護下，不會出現(xiàn)寫丟失情況；

面對這種場景，最簡單的策略便是：強制切主。具體流程如下：

直接從 Mater 進行加載，避免 Slave 查詢到過期數(shù)據(jù)。

SmartDataSource 和 Proxy 都提供了強制切主的設(shè)置方式，在此不做過多介紹。

2、根據(jù) version 進行智能路由

如果下游能拿到最新版本的 version，便可以根據(jù) version 智能的獲取數(shù)據(jù)。

以領(lǐng)域事件場景為例，問題描述如下：

核心流程如下：

1. 業(yè)務(wù)完成后，將變更更新至 DB，Master 更新完成后，直接返回處理結(jié)果；
2. Slave 啟動異步同步，但完成時間不可控；
3. 業(yè)務(wù)發(fā)送 領(lǐng)域事件 至 Topic；
4. 下游業(yè)務(wù)監(jiān)聽消息后，從 Slave 查詢數(shù)據(jù)，如果Slave 尚未同步完成，則出現(xiàn)獲取不到或獲取過期數(shù)據(jù)的問題

針對這個場景，可以引入 version 進行數(shù)據(jù)驗證，基于 Version 的流程如下：

核心流程如下：

1. 業(yè)務(wù)完成后，將業(yè)務(wù)變更和version變更更新至 DB，Master 更新完成后，直接返回處理結(jié)果；
2. Slave 啟動異步同步，但完成時間不可控；
3. 領(lǐng)域事件包含當前的最新 version，將其發(fā)送至 Topic；
4. 下游業(yè)務(wù)監(jiān)聽消息后，先從 Slave 獲取數(shù)據(jù)，并比對兩者的 version

1. 如果大于等于 msg 中的 version，則直接使用；
2. 否則 從 Master 中進行加載，然后執(zhí)行業(yè)務(wù)邏輯

備注：步驟4 中 version 管理應該封裝在服務(wù)接口，對外提供統(tǒng)一的帶 version 參數(shù)的接口；

時間戳是一種特殊的version，可以使用數(shù)據(jù)表的 update_time 作為 version。

3、讀己之寫

讀己之寫，簡單說就是：保存完數(shù)據(jù)后，理解讀取數(shù)據(jù)。

由于復制延時的存在，通常無法立即讀取剛寫入的數(shù)據(jù)，問題流程如下：

核心流程：

1. 業(yè)務(wù)基于 Master 完成操作直接返回，異步并將變更復制到從節(jié)點
2. UI跳轉(zhuǎn)至下一個頁面，該頁面會讀取最新數(shù)據(jù)（詳情頁、列表頁）
3. 由于存在主從復制延時，可能無法獲取最新數(shù)據(jù)

（1）主動延時

最簡單的解法便是，在完成數(shù)據(jù)更新操作后，UI 主動sleep幾秒，然后在進行下一步操作。

整體流程如下：

1. 在跳轉(zhuǎn)新頁面前，增加 loading 頁，主動等待主從完成同步
2. 在系統(tǒng)壓力大時，仍舊無法從根源上解決該問題
3. 由于其簡單性，在項目中也大量使用

（2）UI 動態(tài)添加

主動等待對用戶存在一定的傷害，可以使用動態(tài)添加方案提升用戶體驗。

核心點包括：

1. 更新請求處理完成后，直接返回最新的數(shù)據(jù)，包括新增數(shù)據(jù)或修改后的數(shù)據(jù)；
2. 前端獲取數(shù)據(jù)后，直接在 UI 上進行操作，如將其 append 到 Table 中 或 直接渲染 詳情頁；

（3）智能切主

UI主動添加只是一種障眼法，用戶刷新頁面，仍舊可能看不到最新數(shù)據(jù)，可以試試強制切主

根據(jù)規(guī)則，決定是否強制切主，如下：

1. 根據(jù)業(yè)務(wù)場景，“我的 xxx” 強制切主，其他請求 默認走 Slave
2. 時間間隔，請求時攜帶時間戳或版本，對請求進行切主判斷

四、小結(jié)

簡單回顧，本文概要介紹了“讀寫分離”的方方面面，主要設(shè)計

1. 讀寫分離是提升系統(tǒng)讀性能的重要手段
2. 落地讀寫分離，需要解決復制 和 路由 技術(shù)問題
3. 由于復制延時的存在，對特殊的業(yè)務(wù)場景進行治理