前言

本文討論Connector/J 的loadbalance模塊，我們先觀察整個模塊的大概邏輯結構和每一個大組件的作用，然后在代碼層面分析對于例外的控制，這里會有兩個“區分”：1）區分構造連接程序和使用連接程序；2）區分通訊例外和資料例外，最終分析此模式的實用性，

本次分析的版本為5.1.46，若通過maven下載，可添加以下依賴：

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.46</version>
</dependency>

我們獲取連接的例子如下：

 Connection conn = null;
    URL ＝“jdbc:mysql:loadbalance://ip1:port1,ip2:port2,ip3:port3/dbname”；
    try{
        // 注冊 JDBC 驅動
        Class.forName("com.mysql.jdbc.Driver");

        // 打開鏈接
        conn = DriverManager.getConnection(DB_URL,USER,PASS);
    ....

名詞定義

Mysql：Mysql資料庫管理軟體

Mysql服務器：安裝了Mysql資料庫管理軟體的服務器

呼叫方：呼叫DriverManager#getConnection命令獲取連接的一方

一、Loadbalance的邏輯結構

Loadbalance模塊的UML類圖如下：
主要組件功能如下：

• MysqlIO：負責與Mysql服務器建立tcp鏈接，
• ConnectionImpl、JDBC4Connection：通過MysqlIO控制與Mysql服務器間的連接，并設定和記錄各種連接時間
• MultiHostMySQLConnection、LoadBalancedMySQLConnection、JDBC4LoadBalancedMySQLConnection：通過代理物件LoadBalancedConnectionProxy獲取JDBC4Connection物件，并呼叫JDBC4Connection物件對應的介面方法（從JDBC4MySQLConnection到java.sql.Connection宣告的方法），或者呼叫LoadBalancedConnectionProxy對應的方法，
• BalanceStrategy介面以及其實作類，以各自的演算法回傳合適的連接物件JDBC4Connection，
• MultiHostConnectionProxy：作為各種動態類的父類，實作了各種動態類的公共方法，最常見的就是回傳當前連接物件給到MultiHostMySQLConnection及其子類，它還是InvocationHandler介面的直接實作類，它多載了invoke方法，并宣告了由其子類實作的虛方法invokeMore，invoke方法的實作使用了模板方法這種設計模式，通過invoke方法和類的invokeMore方法，一起實作了代理模式，即在被代理方法執行之前和之后都添加了一些行為，
• LoadBalancedConnectionProxy作為MultiHostMySQLConnection的子類多載了invokeMore方法，在被代理方法執行后，會通過策略物件計算和更新當前連接物件，以供下次使用，

組件呼叫順序：

• 構造連接時各組件呼叫順序：

• 使用連接時各組件呼叫順序：

二、例外處理機制

1.構造階段

在我們的例里，url以jdbc:mysql:loadbalance:作為前綴，當我們使用DriverManager#getConnection命令獲取連接的時候，跟蹤呼叫鏈會一直來到NonRegisteringDriver#connect方法，而該方法分析引數url后，知道這是使用loadbalance模塊，因此就會進入NonRegisteringDriver#connectLoadBalanced方法，該方法將呼叫LoadBalancedConnectionProxy#createProxyInstance方法獲取連接，

在上述呼叫鏈的程序中，并沒有捕獲例外的行為，因此，如果LoadBalancedConnectionProxy#createProxyInstance方法的底層拋出的任何例外都會直接拋向呼叫方，所以呼叫方通常都會有一個獲取SQLException例外的行為，
我們觀察下LoadBalancedConnectionProxy#createProxyInstance方法：

public static LoadBalancedConnection createProxyInstance(List<String> hosts, Properties props) throws SQLException {
        LoadBalancedConnectionProxy connProxy = new LoadBalancedConnectionProxy(hosts, props);

        return (LoadBalancedConnection) java.lang.reflect.Proxy.newProxyInstance(LoadBalancedConnection.class.getClassLoader(), INTERFACES_TO_PROXY, connProxy);
    }

這里只有兩行命令，第一行構造LoadBalancedConnectionProxy物件，根據命令的宣告，它有可能拋出SQLException；第二句是創建動態代理物件，根據命令的宣告，它有可能拋出IllegalArgumentException，這例外是RuntimeException的子類，因此我們只需要著重觀察LoadBalancedConnectionProxy物件的構造程序，

private LoadBalancedConnectionProxy(List<String> hosts, Properties props) throws SQLException {
        super();
	....
        
    }

私有的建構式首先會呼叫父類的建構式，里面會構造JDBC4LoadBalancedMySQLConnection物件，并作為thisAsConnection屬性值，而當前的LoadBalancedConnectionProxy物件作為JDBC4LoadBalancedMySQLConnection物件的thisAsProxy屬性值，在這個程序中，其實不會拋出SQLException例外，
我們再回到LoadBalancedConnectionProxy建構式：

private LoadBalancedConnectionProxy(List<String> hosts, Properties props) throws SQLException {
        super();
	....
        // hosts specifications may have been reset with settings from a previous connection group
        int numHosts = initializeHostsSpecs(hosts, props);

        this.liveConnections = new HashMap<String, ConnectionImpl>(numHosts);
        this.hostsToListIndexMap = new HashMap<String, Integer>(numHosts);
        for (int i = 0; i < numHosts; i++) {
            this.hostsToListIndexMap.put(this.hostList.get(i), i);
        }
        this.connectionsToHostsMap = new HashMap<ConnectionImpl, String>(numHosts);
    ....
        String strategy = this.localProps.getProperty("loadBalanceStrategy", "random");
        if ("random".equals(strategy)) {
            this.balancer = (BalanceStrategy) Util.loadExtensions(null, props, RandomBalanceStrategy.class.getName(), "InvalidLoadBalanceStrategy", null)
                    .get(0);
        } else if ("bestResponseTime".equals(strategy)) {
            this.balancer = (BalanceStrategy) Util
                    .loadExtensions(null, props, BestResponseTimeBalanceStrategy.class.getName(), "InvalidLoadBalanceStrategy", null).get(0);
        } else if ("serverAffinity".equals(strategy)) {
            this.balancer = (BalanceStrategy) Util.loadExtensions(null, props, ServerAffinityStrategy.class.getName(), "InvalidLoadBalanceStrategy", null)
                    .get(0);
        } else {
            this.balancer = (BalanceStrategy) Util.loadExtensions(null, props, strategy, "InvalidLoadBalanceStrategy", null).get(0);
        }
        
		String lbExceptionChecker = this.localProps.getProperty("loadBalanceExceptionChecker", "com.mysql.jdbc.StandardLoadBalanceExceptionChecker");
        this.exceptionChecker = (LoadBalanceExceptionChecker) Util.loadExtensions(null, props, lbExceptionChecker, "InvalidLoadBalanceExceptionChecker", null)
                .get(0);
    ....
        pickNewConnection();
    }

它根據url里的ip:port集合填充了hostsToListIndexMap屬性，key為ip:port的值，value為從0開始的下標值，同時也構造了與ConnectionImpl有關的屬性：liveConnections和connectionsToHostsMap，這兩屬性會在后面添加ConnectionImpl物件，
隨后還會根據url里的loadBalanceStrategy選項構造對應的策略物件，并作為balance屬性值，
最后初始化了例外檢查器exceptionChecker，如果url里有指定的就使用指定的類來構造，沒有的話就使用默認的com.mysql.jdbc.StandardLoadBalanceExceptionChecker物件，
在建構式的方法體里，pickNewConnection方法之前，雖然有些呼叫的方法會拋出例外，但都有捕獲行為，因此到目前為止仍然安全，我們接著進入非常眼熟的pickNewConnection方法一探究竟：

@Override
    synchronized void pickNewConnection() throws SQLException {
    ....
         if (this.currentConnection == null) { // startup
            this.currentConnection = this.balancer.pickConnection(this, Collections.unmodifiableList(this.hostList),
                    Collections.unmodifiableMap(this.liveConnections), this.responseTimes.clone(), this.retriesAllDown);
            return;
        }
   ....
    }

該方法被currentConnection 屬性是否為空區分出兩種呼叫場景，在構造動態代理連接的時候，currentConnection 屬性肯定為空，根據代碼，它會通過balancer的pickConnection方法獲取底層連接，
我們假設balancer使用的是RandomBalanceStrategy，它的pickConnection方法就是隨機的從url里挑出一個ip:port組合并建立連接，若第一次不成功將會再次嘗試隨機挑選ip:port組合并建立連接，在允許嘗試次內成功建立連接的話，就正常回傳，否則會拋出通訊例外，另外，一旦出現資料例外，也會立即拋出例外，由于篇幅關系，在此不貼出代碼了，

小結

在構造動態代理連接時，如果所有的ip:port都未能成功建立連接，通訊例外會拋向呼叫者，如果建立連接中出現資料例外，該例外也會拋向呼叫者，或者說在構造階段，呼叫者能夠感知到資料例外以及極端情況下的通訊例外，

2.使用階段

MultiHostConnectionProxy直接多載了java.lang.reflect.InvocationHandler介面的invoke方法，我們先觀察一下：

public synchronized Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        ....
        try {
            return invokeMore(proxy, method, args);
        } catch (InvocationTargetException e) {
            throw e.getCause() != null ? e.getCause() : e;
        } catch (Exception e) {
            // Check if the captured exception must be wrapped by an unchecked exception.
            Class<?>[] declaredException = method.getExceptionTypes();
            for (Class<?> declEx : declaredException) {
                if (declEx.isAssignableFrom(e.getClass())) {
                    throw e;
                }
            }
            throw new IllegalStateException(e.getMessage(), e);
        }
    }

該方法的省略部分不會拋例外，但它對invokeMore有一個獲取例外的行為，并且區分了InvocationTargetException和其他的情況的例外，從這里來看，底層拋上來的例外都會往呼叫者拋，而invokeMore方法被LoadBalancedConnectionProxy多載，我們進一步觀察下：

@Override
    public synchronized Object invokeMore(Object proxy, Method method, Object[] args) throws Throwable {
       ....
        Object result = null;
        try {
            result = method.invoke(this.thisAsConnection, args);
		....
        } catch (InvocationTargetException e) {
            dealWithInvocationException(e);

        } finally {
        ....
        }

        return result;
    }

在方法里我們看到有捕獲InvocationTargetException 的行為，因為以反射的形式呼叫，所以一旦有問題會以InvocationTargetException的形式拋出，也就是說，底層發生的例外都會被捕獲到，MultiHostConnectionProxy#dealWithInvocationException方法進一步分析原始例外型別：

void dealWithInvocationException(InvocationTargetException e) throws SQLException, Throwable, InvocationTargetException {
        Throwable t = e.getTargetException();

        if (t != null) {
            if (this.lastExceptionDealtWith != t && shouldExceptionTriggerConnectionSwitch(t)) {
                invalidateCurrentConnection();
                pickNewConnection();
                this.lastExceptionDealtWith = t;
            }
            throw t;
        }
        throw e;
    }

從代碼結構上看，例外是一定會往上拋，因為MultiHostConnectionProxy#dealWithInvocationException方法是在LoadBalancedConnectionProxy#invokeMore的catch代碼塊里呼叫，而該catch代碼塊沒有進一步捕獲例外，因此例外將到達MultiHostConnectionProxy#invoke方法里的捕獲例外的代碼塊，前文通過觀察它的捕獲例外代碼塊可知道，例外最侄訓繼續向上層拋，也就是說，在使用連接的程序中，一旦遇到通訊例外或者資料例外，呼叫者都會感知到，當例外發生時，我們可以基本知道它經過的地方：

我們把目光放回到MultiHostConnectionProxy#dealWithInvocationException:

void dealWithInvocationException(InvocationTargetException e) throws SQLException, Throwable, InvocationTargetException {
        Throwable t = e.getTargetException();

        if (t != null) {
            if (this.lastExceptionDealtWith != t && shouldExceptionTriggerConnectionSwitch(t)) {
                invalidateCurrentConnection();
                pickNewConnection();
                this.lastExceptionDealtWith = t;
            }
            throw t;
        }
        throw e;
    }

呼叫的shouldExceptionTriggerConnectionSwitch被LoadBalanceConnectionProxy多載了：

@Override
    boolean shouldExceptionTriggerConnectionSwitch(Throwable t) {
        return t instanceof SQLException && this.exceptionChecker.shouldExceptionTriggerFailover((SQLException) t);
    }

我們假設exceptionChecker使用的是默認的com.mysql.jdbc.StandardLoadBalanceExceptionChecker
該類有兩個集合sqlStateList和sqlExClassList，而集合的元素分別來自于url的loadBalanceSQLStateFailover和loadBalanceSQLExceptionSubclassFailover選項，看官可以通過官網了解這兩選項，在此不詳述，
shouldExceptionTriggerFailover方法在以下情況此方法會回傳true：

• 錯誤碼以08開頭
• 錯誤碼雖然不以08開頭，但錯誤碼以sqlStateList任一元素值開頭
• 拋出的例外是通訊例外CommunicationsException
• 拋出的例外型別是sqlExClassList任一元素的例外型別相等或者是子類，
  也就是說，只要是通訊例外或者用戶指定的例外，該方法都會回傳true，
  我們再次結合MultiHostConnectionProxy#dealWithInvocationException來看：

void dealWithInvocationException(InvocationTargetException e) throws SQLException, Throwable, InvocationTargetException {
        Throwable t = e.getTargetException();

        if (t != null) {
            if (this.lastExceptionDealtWith != t && shouldExceptionTriggerConnectionSwitch(t)) {
                invalidateCurrentConnection();
                pickNewConnection();
                this.lastExceptionDealtWith = t;
            }
            throw t;
        }
        throw e;
    }

如果例外屬于通訊例外以及用戶指定的情況一旦發生，首先更新連接，然后將例外往上拋，

小結

動態代理連接在構造階段和使用階段，一旦遇到任何例外，都會被呼叫者感知到（構造階段遇到所有的ip:port連接失敗才拋出通訊例外），這一點與failover確實不一樣，在使用階段，呼叫者可以馬上停止當前事務程序而重新再來，這樣會讓事務操作變得可以掌控，也可以說事務的原子性得以保證，它的這種特性，也符合我們使用普通Connection時的編程規范（try…事務操作…catch…回滾事務…finally…關閉資源…），因此，如果我們專案一開始比較小，使用普通的Connection模式，到后來需要資料庫結構升級為支持多主機的時候，我們不需要修改代碼，只需要修改下url配置即可，

三、autoReconnect選項

根據官網介紹autoReconnect選項是failover模塊重要選項之一，在loadbalance的描述部分只字未提，但我們通過閱讀代碼時會看到它的身影，本節就一起分析該選項所起到的作用，
該選項對應著autoReconnect屬性，而該項屬性被使用到的地方僅在于
LoadBalancedConnectionProxy#invokeMore方法：

@Override
    public synchronized Object invokeMore(Object proxy, Method method, Object[] args) throws Throwable {
        String methodName = method.getName();
        if (this.isClosed && !allowedOnClosedConnection(method) && method.getExceptionTypes().length > 0) {
            if (this.autoReconnect && !this.closedExplicitly) {
                // try to reconnect first!
                this.currentConnection = null;
                pickNewConnection();
        	....
        Object result = null;
        try {
            result = method.invoke(this.thisAsConnection, args);
           ....
        return result;
    }

在Method#invke前，它是呼叫pickNewConnection的條件之一，我們分析下各項條件成立的因素：

• this.isClosed為真值
  該值為真值的地方出現在：
  1）pickNewConnection方法體里，如果url的ip:port都不能成功建立連接，就為真值，
  2）doPing方法體里，如果未能ping成功，就為真值，
  3）執行連接的close方法
  4）執行連接的abortInternal方法
  5）執行連接的abort方法
• !allowedOnClosedConnection為真值
  只要不執行連接的以下方法就會成立：
  1）連接的getAutoCommit方法
  2）連接的getCatalog方法
  3）連接的getTransactionIsolation方法
  4）連接的getSessionMaxRows方法
• method.getExceptionTypes().length > 0
  只要方法宣告會拋例外即滿足，
• this.autoReconnect
  url上添加autoReconnect=true選項即滿足，
• !this.closedExplicitly
  不執行連接的close方法即可為真：

作用分析

所以假設用戶在url添加了autoReconnect=true的情況下，并且呼叫方呼叫動態連接的上一條命令不是close方法情況下,大致可以梳理出以下2個場景：
1）用戶已經成功獲取動態代理，在使用時由于網路原因使得url里所有的ip:port都不能成功建立連接，前文講述過invokeMore方法遇到通訊例外時，最侄訓執行pickNewConnection方法并拋出通訊例外，如果url里所有的ip:port都未能成功建立連接，isClosed為true，當網路恢復正常，重新執行的操作會先嘗試更新連接，
2）呼叫者先呼叫接連的abort或者abortInternal方法，然后再執行增刪改查的命令，也就是說呼叫方可能通過呼叫abort或者abortInternal方法主動地更換連接，然后再操作資料，

對于前一點，當網路出現極端情況下，極大方便了開發人員，因為他們不必考慮如何解決這種情況下的重連，另外，也可以理解為是一個兜底的保障作用，確保一旦網路恢復后，仍能正常執行SQL操作，
對于第二點，可理解為給呼叫者提供更靈活的手段，在需要的時候呼叫abort或者abortInternal命令更換連接，然后再進行SQL操作，所以說它是讓這個機制更完善，

所以，基于上面的分析，官網上其實可以多作介紹的，

四、何時重建連接

重建連接的操作以LoadBalancedConnectionProxy#pickNewConnection為入口，該方法會輪循url各組ip:port，只要有一組能夠連接成功就算建立了與Mysql的連接，如果沒有一組能夠成功建立連接，設定isClosed為true，
那么該方法中哪些時間點上會被呼叫呢？

1. 構造動態代理連接j時，LoadBalancedConnectionProxy的建構式會呼叫該方法，
2. 正式呼叫Method#invoke方法前有可能執行，請看上一節，
3. 呼叫Method#invoke方法出現了通訊例外，
4. 執行完commit或者rollback方法后，

所以，如果某個ip:port對應的底層連接能夠正常作業，它就有可能不會被更換，之所以說有可能，是因為當呼叫者關閉自動提交，執行完SQL命令后，發送commit或者rollback命令時，它將被更換，也就是說，當一筆事務完成了就需要更換底層連接，這樣從另一個角度看，它至少保證了事務內的命令只由一個底層的連接傳送，這樣就不會出現一筆事務內的命令有的在A服務器運行有的在B服務器運行，確保資料的一致性，如果呼叫者沒有關閉自動提交，執行查詢命令或者更新單筆資料，底層連接不會更換，

五、實用性分析

動態代理連接在使用中遇到例外能夠被呼叫方即時感知到，這使得loadbalance模式具有使用的價值，故名思義，真讓人以為此模式能起到負載均衡的效果，但根據前面切換連接的分析，并不是那回事，它其實是遇到通訊例外時，更換底層連接，讓呼叫者繼續使用動態代理發送SQL命令，所以，這里涉及到Ｍysql多機部署和資料一致性的問題，

• 對于微型專案，可以采用如下結構：
  讓兩臺Mysql服務器互為主備，

• 讓高可用性上一個臺階，可使用Percona XtraDB：
  它可實作集群內所有Mysql服務器資料的強一致性，但是如果成員太多，為保持資料的一致性會導致性能有所下降，

• 使用資料庫中間件和集群
  此方法由中間件分析出SQL操作是讀操作還是寫操作，然后將操作分配給專門用于讀的服務器或者專門用于接受寫命令的服務器，此方案要求最高，但它兼顧了高可用和性能，

六、總結

Loadbalance模式具有使用價值，其特點如下：

• 呼叫者在使用程序中能夠感知到底層發生的例外，另外呼叫者只需構造一個動態代理連接即可，
• 呼叫者在使用程序中遇到例外，處理方法與使用普通的Connection一樣，使用者如果想從普通的Connection升級到Loadbalance模式，在應用層面只需要修改url，無需改代碼，
• 可擴展性強，用戶發現資料庫資源占用高，可以多安排設備，然后在url里添加更多的ip:port即可，
• Loadbalance模式會更換底層連接，所以需要部署多臺Mysql服務器，另外，當前一筆事務正常運行完畢，下一筆事務遇到通訊例外，底層連接就會被替換，下次重新執行第二筆事務將在另外一臺服務器上執行，所以這里存在資料同步問題，所以使用此模式，需要掌握Mysql多機的部署知識，而且必須要將資料的一致性放在最首要的位置來考慮，
• 高可用性，根據上一點，使用好Loadbalance模式，無形中實作了資料的高可用性，

根據“四、何時重建連接”一節可知，Loadbalace模式通常在遇到通訊例外或者提交/回滾事務的時候才更換連接，它的核心目的只不過是讓呼叫者可以重復使用動態代理連接，此Loadbalance與我們想象中的負載均衡不是同一個概念，如果用戶對回應速度有比較高的要求，這種模式就不能勝任了，后續文章將介紹replication模式，看看它在提高回應速度方面有何設計良方，