Hibernate Shards 資料的水平、垂直切割（三）- Hibernate Shards結構

主要處理方式
hibernate shards的主要工作方式如:
    
他在hibernate的基礎上實現了一層資料切分的處理邏輯。不需要切分的資料直接使用hibernate的SessionFactory和Session進行操作；需要切分的資料，則使用hibernate shards的ShardedSessionFactory和ShardedSession進行操作
hibernate shards的主要任務:
1. 對shards配置的處理
2. 提供一個可擴充的sharding機制，能方便的運用各種sharding策略以及resharding支援等要求
3. 根據配置和sharding機制正確的存取資料

    shards的配置主要包含每個shard對應的資料庫連接資訊，以及定義一個shard id
    為了充分實現伸縮性以及簡化商務邏輯的開發，sharding策略應當以實體id為基礎，這樣在類似hibernate Session這樣的資料操作介面上實現
sharding處理會比較容易，對商務邏輯代碼的開發也能比較透明
    中get, update, delete等操作都可以取到實體id，然後根據sharding策略的演算法計算出shard id，從對應的資料庫中執行這些操作。hibernate shards中與這一操作相關的介面是ShardResolutionStrategy
    sharding環境下的save操作涉及到id的產生機制，以及將資料按照sharding策略insert到正確的shard中。hibernate shards中與這一操作相關的介面是ShardSelectionStrategy
    query操作通過hql、Criteria等方式查詢結果集，這些查詢有可能需要在某個shard或某幾shards中進行，也可能需要在全部的shards中進行，與具體業務相關。hibernate shards中與這一操作相關的介面是ShardAccessStrategy
    在resharding的支援方面，hibernate shards實現了virtual shards
    在resharding時主要任務有2個，其一是對sharding演算法、配置的修改，其二是對已有資料的重分區處理。
如果最開始進行sharding設計時考慮不夠完整，resharding時可能會很麻煩。
virtual shards方式在於在一開始就考慮到後續的resharding需求，估算出最大需要的shards數量，以估算出的這個數量配置虛擬shard，然後將虛擬shard映射到當前的實際shard中
    比如對某個資料，目前使用2個shard就足夠了，但考慮到後續的業務增長，設定100個虛擬shard，sharding演算法均以這100個虛擬shard為基礎，然後將虛擬shard 50個一組映射到當前使用的實際shard上。
這樣在後續需要resharding時，只需要對資料重分區以及修改虛擬shard和實際shard的映射配置就可以，風險比較小

Configuration的處理
configuration部分類圖如下:
    
從前面一篇Hibernate Shards 資料的水平、垂直切割（二）- Hibernate Shards基本示範已經看到了
載入設定檔以及建立ShardedSessionFactory的過程

ShardConfiguration用來表示每個shard特有的配置資訊，包括：
hibernate.connection.url
hibernate.connection.username
hibernate.connection.password
hibernate.session_factory_name
hibernate.connection.datasource
hibernate.cache.region_prefix
hibernate.connection.shard_id

ShardedConfiguration則持有所有shards對應的ShardConfiguration列表、一個作為原型的Configuration對象以及一個sharding策略的工廠對象ShardStrategyFactory
構造ShardedConfiguration時，他從各個設定檔讀取shard配置資訊，得到virtual shards與實際shards列表以及之間的映射關係
ShardedConfiguration還具有建立ShardedSessionFactory的職責。在建立ShardedSessionFactory時，hibernate
shards迴圈為每個shard建立一個hibernate的SessionFactory對象，丟給ShardedSessionFactory建構函式
每一個hibernate的SessionFactory對象都是通過原型Configuration來建立的，只是在迴圈中會將每個shard特有的配置資訊（ShardConfiguration的屬性）設定到原型Configuration中，再用它來建立SessionFactory對象，這是一種簡單的處理方式，避免再去建立額外的設定檔

關鍵實現
hibernate shards的關鍵實現部分類圖如下:
    
處理上非常簡單，hibernate shards重新實現了hibernate的Session、SessionFactory介面。在前面的configuration處理中，ShardedConfiguration在建立
ShardedSessionFactory時將每個shard對應的hibernate SessionFactory列表傳給了ShardedSessionFactory。ShardedSession的主要工作就是調用相關的sharding策略類確定目標shard，
使用與他對應的SessionFactory建立hibernate的Session對象，執行操作。對於使用了sharding之後不支援的方法則拋出異常。當然其中會有像query這樣特殊的操作（涉及到合并結果集、排序、distinct等一些較麻煩的處理），還要處理一些hibernate lazy
loading、detached object等相關的問題，以及其他一些sharding中必須處理的問題，例如cross-shard等
對於hibernate的Criteria、Query等對象，hibernate shards也都實現了Sharded***的版本，用於支援針對shard的query操作

Shards Strategy
shards策略的類圖:
    
ShardSelectionStrategy: 為新增的實體選擇shard id，用於save操作的情境，介面方法中傳入要執行操作的實體物件
ShardResolutionStrategy: 根據實體類名和id計算出與其對應的shard id，一般用於get、load、update、delete等操的情境，介面方法中會傳入實體類名和實體id
ShardAccessStrategy: 主要用於hql、Criteria等查詢情況，因其設計機制以及需要處理的事情方面存在些共同性，因此所有的get方法最終也通過ShardAccessStrategy來載入資料。
他只是迴圈為每個目標shard調用ShardOperation<T>的execute方法，把結果丟給ExitStrategy<T>處理。get操作時目標shard是一個明確的shard（通過ShardResolutionStrategy得到），而query操作時則是全部的shard列表（可以通過自訂的ShardAccessStrategy改變）
    hibernate shards提供了2個ShardAccessStrategy的實現:
    SequentialShardAccessStrategy: 逐個shard順序執行，由ExitStrategy<T>決定是否結束執行過程以及如何處理結果集
    ParallelShardAccessStrategy: 並行的在各個shard執行查詢操作，由ExitStrategy<T>決定如何處理結果集
    ShardAccessStrategy載入資料時用到了下面一些介面:
    ShardOperation<T>: 這個是在每個shard上真正執行get或者query動作的介面，get和query操作時通過匿名類實現這個介面
    ExitStrategy<T>: 這個介面的職責是解決如何處理結果集的問題，以及在SequentialShardAccessStrategy這樣的情境下是否該結束對後續shard的執行
        對每個shard執行完讀取操作後調用該介面的方法addResult，把執行結果丟給他；整個執行結束後調用該介面的compileResults方法處理結果集，並返回給調用者
        FirstNonNullResultExitStrategy: 查詢到對象即返回，用於get的情況
        ConcatenateListsExitStrategy: 語義上是合并結果集，返回給調用者，用於hql和Criteria查詢。他使用ExitOperationsCollector來完成這一任務
    ExitOperationsCollector: 處理如何合并結果集的邏輯。目前對於hql查詢均使用ExitOperationsQueryCollector，他把從各個shard執行的結果集合并返回給調用者；對於criteria查詢使用ExitOperationsCriteriaCollector，他在處理結果集時使用另一介面ExitOperation的實現，來處理count、sum、distinct等操作。目前hibernate shards沒有對hql進行解析，因此hql中的count、sum、distinct等這樣的操作還無法支援

限制
1. 還有很多hibernate的API沒有實現
2. 不支援cross-shard的對象關係，比如A、B之間存在關聯關係，而A、B位於不同的shard中。hibernate shards提供了CrossShardRelationshipDetectingInterceptor，以hibernate Interceptor的方式來檢測cross-shard的對象關係問題，但這個攔截器有一定的開銷（比如需要查映射的中繼資料、有可能過早的觸發消極式載入行為等），可以用於測試環境來檢測cross-shard關係的問題
3. hibernate shards本身不支援分散式交易，若要使用分散式交易需要採用其他解決方案
4. hql、criteria存在不少限制，相比於hql，criteria支援的特性更多一些
5. Session或者SessionFactory上面有狀態的攔截器，在shard環境下面會存在一些問題。拿session來說，在hibernate中攔截器是對單個session上的多次sql執行事件進行攔截，而在shard情況下hibernate shards的ShardedSession會對應每個shard建立一個session，這時攔截器就是跨多個session了，因此hibernate shards要求有狀態的攔截器必須通過實現StatefulInterceptorFactory來提供新的執行個體。如果攔截器需要使用到目標shard的session，則必須實現hibernate shards的RequiresSession介面