[[348954]]

本文轉載自微信公眾號「猿天地」，作者尹吉歡 。轉載本文請聯系猿天地公眾號。 

讀寫分離是應用中提升數據訪問性能最常見的一種技術，當用戶量越來越多，訪問量越來越大，單節點數據庫難免會遇到性能瓶頸。很多場景基本上都是讀多寫少，所以增加多個從節點來分擔主節點的壓力自然是水到渠成的事情。

在應用接入讀寫分離后，難免會有一些我們意料之外的問題，這篇文章主要給大家介紹下一些經常會遇到的問題，有其他的問題歡迎留言補充。

實現方式

對于讀寫分離的使用，主要分為兩種方式，客戶端方式和代理方式。

客戶端方式可以自己用 Spring 自帶的 AbstractRoutingDataSource 來實現，也可以用開源的框架來實現，比如 Sharding-JDBC。

代理方式需要編寫代理服務來對所有節點進行管理，應用不需要關注多個數據庫節點信息。可以自己實現，也可以用開源的框架，也可以用商業的云服務。

數據延遲

談到數據延遲，你先得理解主從架構的原理。對數據的增刪改操作在主庫上執行，查詢在從庫上執行，當數據剛插入到主庫，然后馬上去查詢的時候，很有可能數據還沒同步到從庫上，就會出現查詢不到的情況。

像我之前在某些網站發表文章，發表之后跳轉到列表頁面，發現沒有新發表的文章，重新刷新下頁面又有了，這一看這就是讀寫分離后的數據延遲導致的現象。

強制路由數據延遲要不要解決，一般取決于業務場景。對于實時性要求沒有那么高的業務場景，允許一定的延遲，對于實時性要求高的場景，唯一的方式就是直接從主庫進行查詢，這樣才能及時讀到剛插入或者修改后最新的數據。

強制路由

就是一種解決方案，也就是將讀請求強制分發到主庫進行查詢。大部分中間件都支持 Hint 語法/FORCE_MASTER/和/FORCE_SLAVE/。

以 Sharding-JDBC 舉例，框架提供了 HintManager 來強制路由，使用方式如下：

HintManager hintManager = HintManager.getInstance(); 
hintManager.setMasterRouteOnly(); 

為了方便使用，建議封裝一個注解，在需要實時查詢的業務方法上加上注解，通過切面進行強制路由的設置。

注解使用：

@MasterRoute 
@Override 
public UserBO getUser(Long id) { 
    log.info("查詢用戶 [{}]", id); 
    if (id == null) { 
        throw new BizException(ResponseCode.PARAM_ERROR_CODE, "id不能為空"); 
    } 
    UserDO userDO = userDao.getById(id); 
    if (userDO == null) { 
        throw new BizException(ResponseCode.NOT_FOUND_CODE); 
    } 
    return userBoConvert.convert(userDO); 
} 

切面設置：

@Aspect 
public class MasterRouteAspect { 
    @Around("@annotation(masterRoute)") 
    public Object aroundGetConnection(final ProceedingJoinPoint pjp, MasterRoute masterRoute) throws Throwable { 
        HintManager hintManager = HintManager.getInstance(); 
        hintManager.setMasterRouteOnly(); 
        try { 
            return pjp.proceed(); 
        } finally { 
            hintManager.close(); 
        } 
    } 
} 

事務操作

在事務中的讀請求，走主庫還是從庫呢?對于這個問題，最簡單的方式就是所有事務中的操作都走主庫，在事務中經常會存在插入，然后再重新查詢的場景，此時事務沒提交，就算同步很快，從庫也是沒有數據的，所以只能走主庫。

但還有一些請求，只需要查詢從庫就行了，如果針對所有事務中的操作都強制路由，也不是很好。在 Sharding-JDBC 中的做法挺好的，對于同一線程且同一數據庫連接內，如有寫入操作，以后的讀操作均從主庫讀取，用于保證數據一致性。如果我們在數據寫入之前有查詢請求，還是走的從庫，減輕主庫壓力。

動態強制路由

在功能開發的時候就決定了哪些接口要強制走主庫，這個時候我們會在代碼上進行路由的控制，也就是前面講的自定義注解。如果有些是沒有加的，但是在線上運行的時候發現還是要走主庫才可以，這個時候就需要改代碼重新發布了。

動態強制路由可以結合配置中心來實現，通過配置的方式來決定哪些接口要強制路由，然后在 Filter 中通過 HintManager 來設置，避免改代碼重啟。

也可以通過切面精確到業務方法級別的動態路由配置。

流量分發

場景一：

假設你有一個主節點，兩個從節點，讀請求較多，兩個從節點壓力有點大。這個時候只能增加第三個從節點來分擔壓力。現象是主庫的壓力并不大，寫入較少，從成本來考慮，是否可以不增加第三個從節點呢?

場景二：

假設你有一個 8 核 64G 的主庫，8 核 64G 的從庫，4 核 32G 的從庫，從配置上來看，4 核 32G 的從庫處理能力肯定是要低于其他兩個的，這個時候如果我們沒有定制流量分發的比例，就會出現低配數據庫壓力過高而導致的問題。當然這個也能避免使用不同規則的從庫。

上面的場景需要能夠對請求進行管理，在 Sharding-JDBC 中提供了讀寫分離的路由算法，我們可以自定義算法來進行流量的分發管理。

實現算法類：

public class KittyMasterSlaveLoadBalanceAlgorithm implements MasterSlaveLoadBalanceAlgorithm { 
    private RoundRobinMasterSlaveLoadBalanceAlgorithm roundRobin = new RoundRobinMasterSlaveLoadBalanceAlgorithm(); 
    @Override 
    public String getDataSource(String name, String masterDataSourceName, List<String> slaveDataSourceNames) { 
        String dataSource = roundRobin.getDataSource(name, masterDataSourceName, slaveDataSourceNames); 
        // 控制邏輯，比如不同的從節點（配置不同）可以有不同的比例 
        return dataSource; 
    } 
    @Override 
    public String getType() { 
        return "KITTY_ROUND_ROBIN"; 
    } 
    @Override 
    public Properties getProperties() { 
        return roundRobin.getProperties(); 
    } 
    @Override 
    public void setProperties(Properties properties) { 
        roundRobin.setProperties(properties); 
    } 
} 

基于 SPI 機制的配置：

org.apache.shardingsphere.core.strategy.masterslave.RoundRobinMasterSlaveLoadBalanceAlgorithm 
org.apache.shardingsphere.core.strategy.masterslave.RandomMasterSlaveLoadBalanceAlgorithm 
com.cxytiandi.kitty.db.shardingjdbc.algorithm.KittyMasterSlaveLoadBalanceAlgorithm 

讀寫分離的配置：

spring.shardingsphere.masterslave.load-balance-algorithm-class-name=com.cxytiandi.kitty.db.shardingjdbc.algorithm.KittyMasterSlaveLoadBalanceAlgorithm 
spring.shardingsphere.masterslave.load-balance-algorithm-type=KITTY_ROUND_ROBIN 

關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。