中间表增加额外字段_如何定制分表中间件
前言
一般來說，影響數據庫最大的性能問題有兩個，一個是對數據庫的操作，一個是數據庫中的數據太大。對于前者我們可以借助緩存來減少一部分讀操作，針對一些復雜的報表分析和搜索可以交給?Hadoop?和?ElasticSearch?。對于后者，我們就只能分庫分表，讀寫分離。
互聯網行業隨著業務的復雜化，大多數應用都會經歷數據的垂直分區。一個復雜的流程會按照領域拆分成不同的服務，每個服務中心都擁有自己獨立的數據庫。拆分后服務共享，業務更清晰，系統也更容易擴展，同時減少了單庫數據庫連接數的壓力，也在一定程度上提高了單表大數據量下索引查詢的效率。當然業務隔離，也可以避免一個業務把數據庫拖死導致所有業務都死掉，我們將這種按照業務維度，把一個庫拆分為多個不同的庫的方式叫做垂直拆分。
垂直拆分也包含針對長表(屬性很多)做冷熱分離的拆分。例如，在商品系統設計中，一個商品的生產商、供銷商以及特有屬性，這些字段變化頻率低，查詢次數多，叫做冷數據；而商品的份額，關注量等類似的統計信息變化頻率較高，叫做活躍數據或者熱數據。在 MySQL 中，冷數據查詢多更新少，適合用 MyISAM 存儲引擎，而熱數據更新比較頻繁適合用 InnoDB，這也是垂直拆分的一種。
當單表數據量隨著業務發展繼續膨脹，在 MySQL 中當數據量達到千萬級時，就需要考慮進行水平拆分了，這樣數據就分散到不同的表上，單表的索引大小得到控制，可以提升查詢性能。當數據庫的實例吞吐量達到性能瓶頸后，我們需要水平擴展數據庫的實例，讓多個數據庫實例分擔請求，這種根據分片算法，將一個庫拆分成多個一樣結構的庫，將多個表拆分成多個結構相同的表就叫做水平拆分。
圖1
數據拆分也有很多缺點，數據分散，數據庫的 Join 操作變得更加復雜，分片后數據的事務一致性很難保證，同時數據的擴容和維護難度增加，拆分規則也可能導致某個業務需要同時查詢所有的表然后進行聚合。如果需要排序和函數計算則更加復雜，所以不到萬不得已可以先不必拆分。
根據分庫分表方案中實施切片邏輯的層次不同，我們將分庫分表的實現方案分成以下4種：
1. 在應用層直接分片
這種方式將分片規則直接放在應用層，雖然侵入了業務，開發人員不僅既需要實現業務邏輯也需要實現分庫分表的配置的開發，但是實現起來簡單，適合快速上線，通過編碼方式也更容易實現跨表遍歷的情況。后期故障也更容易定位，大多數公司都會在業務早期采用此種方式過渡，后期分表需求增多，則會尋求中間件來解決，以下代碼為銅板街早期訂單表在 DAO 層將分片信息以參數形式傳到 mybatis 的 mapper 文件中的實現方案。
1@Override2public?OrderDO?findByPrimaryKey(String?orderNo)?{
3
4????Assert.hasLength(orderNo,?"訂單號不能為空");
5
6????Map<String,?Object>?map?=?new?HashMap<String,?Object>(3);
7????map.put("tableSuffix",?orderRouter.routeTableByOrderNo(orderNo));
8????map.put("dbSuffix",?orderRouter.routeDbByOrderNo(orderNo));
9????map.put("orderNo",?orderNo);
10
11????Object?obj?=?getSqlSession().selectOne("NEW_ORDER.FIND_BY_PRIMARYKEY",?map);
12????if?(obj?!=?null?&&?obj?instanceof?OrderDO)?{
13????????return?(OrderDO)?obj;
14????}
15????return?null;
16}
2. 在ORM層直接分片
這種方式通過擴展第三方 ORM 框架，將分片規則和路由機制嵌入到 ORM 框架中，如hibernate 和 mybatis，也可以基于 spring jdbctemplate 來實現，目前實現方案較少。
3. 客戶端定制 JDBC 協議
這種方式比較常見對業務侵入低。通過定制 JDBC 協議，針對業務邏輯層提供與 JDBC一致的接口，讓開發人員不必要關心分庫分表的具體實現，分庫分表在 JDBC 內部搞定，對業務層透明。目前流行的 ShardingJDBC、TDDL 便采用了這種方案。這種方案需要開發人員熟悉 JDBC 協議，研發成本較低，適合大多數中型企業。
4. 代理分片
此種分片方式，是在應用層和數據庫層增加一個代理，把分片的路由規則配置在代理層，代理層提供與 JDBC 兼容的接口給應用層，開發人員不用關心分片邏輯實現，只需要在代理層配置即可。增加代理服務器，需要解決代理的單點問題增加硬件成本，同時所有的數據庫請求增加了一層網絡傳輸影響性能，當然維護也需要更資深的專家，目前采用這種方式的框架有 cobar 和 mycat。
圖2
切片算法
選取分片字段
分片后，如果查詢的標準是根據分片的字段，則根據切片算法，可以路由到對應的表進行查詢。如果查詢條件中不包含分片的字段，則需要將所有的表都掃描一遍然后在進行合并。所以在設計分片的時候我們一般會選擇一個查詢頻率較高的字段作為分片的依據，后續的分片算法會基于該字段的值進行。例如根據創建時間字段取對應的年份，每年一張表，取電話號碼里面的最后一位進行分表等，這個分片的字段我們一般會根據查詢頻率來選擇。例如在互金行業，用戶的持倉數據，我們一般選擇用戶 id 進行分表，而用戶的交易訂單也會選擇用戶 id 進行分表，但是如果我們要查詢某個供應商下在某段時間內的所有訂單就需要遍歷所有的表，所以有時候我們可能會需要根據多個字段同時進行分片，數據進行冗余存儲。
分片算法
分片規則必須保證路由到每張物理表的數據量大致相同，不然上線后某一張表的數據膨脹的特別快，而其他表數據相對很少，這樣就失去了分表的意義，后期數據遷移也有很高的復雜度。通過分片字段定位到對應的數據庫和物理表有哪些算法呢？(我們將分表后在數據庫上物理存儲的表名叫物理表，如 trade_order_01，trade_order_02，將未進行切分前的表名稱作邏輯表如 trade_order)大致可以有以下分類：
按日期 如年份，季度，月進行分表，這種維度分表需要注意在邊緣點的垮表查詢。例如如果是根據創建時間按月進行分片，則查詢最近3天的數據可能需要遍歷兩張表，這種業務比較常見，但是放中間件層處理起來就比較復雜，可能在應用層特殊處理會簡單點。
哈希 ，這種是目前比較常用的算法，但是這里謹慎推薦，因為他的后期擴容是件很頭痛的事情，例如根據用戶 ID 對64取模，得到一個0到63的數字，這里最多可以切分64張表{0，1，2，3，4… 63}，前期可能用不到這么多，我們可以借助一致性哈希的算法，每4個連續的數字分成放到一張表里。例如 0，1，2，3 分到00這張表，4，5，6，7分到04這張表，用算法表示 floor(userID % 64 / 4) * 4 假設 floor為取整的效果。
????圖3
按照一致性哈希算法，當需要進行擴容一倍時需要遷移一半的數據量，雖然不至于遷移所有的數據，如果沒有工具也是需要很大的開發量。下圖中根據分表字段對16取余后分到4張表中，后面如果要擴容一倍則需要遷移一半的數據。
????圖4
截取 這種算法將字段中某一段位置的數據截取出來，例如取電話號碼里面的尾數，這種方式實現起來簡單，但在上線前一定要預測最終的數據分布是否會平均。比如地域，姓氏可能并不平均等,以4結尾的電話號碼也相對偏少。
特別注意點
分庫和分表算法需要保證不相關,上線前一定要用線上數據做預測。例如分庫算法用“用戶idd 分64個庫” 分表算法也用 “用戶idd 分64張表”，總計 64 * 64 張表，最終數據都將落在 以下 64張表中 00庫00表，01庫01表… 63庫63表， 其他 64 * 63張表則沒有數據。這里可以推薦一個算法，分庫用 用戶ID/64 % 64 , 分表用 用戶IDd 測試1億筆用戶id發現分布均勻。
在分庫分表前需要規劃好業務增長量，以預備多大的空間，計算分表后可以支持按某種數據增長速度可以維持多久。
如何實現客戶端分片
客戶端需要定制 JDBC 協議，在拿到待執行的 sql 后，解析 sql，根據查詢條件判斷是否存在分片字段。如果存在，再根據分片算法獲取到對應的數據庫實例和物理表名，重寫 sql，然后找到對應的數據庫 datasource 并獲取物理連接，執行 sql，將結果集進行合并篩選后返回。如果沒有分片字段，則需要查詢所有的表，注意，即使存在分片字段，但是分片字段在一個范圍內，可能也需要查詢多個表，針對 select 以外的 sql 如果沒有傳分片字段建議直接拋出異常。
圖5
JDBC 協議
我們先回顧下一個完整的通過 JDBC 執行一條查詢 sql 的流程，其實 druid 也是在 JDBC 上做增強來做監控的，所以我們也可以適當參考 druid 的實現。
1@Test2public?void?testQ()?throws?SQLException,NamingException{
3????Context?context?=?new?InitialContext();
4????DataSource?dataSource?=?(DataSource)context.lookup("java:comp/env/jdbc/myDataSource");
5????Connection?connection?=?dataSource.getConnection();
6????PreparedStatement?preparedStatement?=?connection.prepareStatement("select?*?from?busi_order?where?id?=??");
7????preparedStatement.setString(1,"1");
8????ResultSet?resultSet?=?preparedStatement.executeQuery();
9????while(resultSet.next()){
10???????String?orderNo?=??resultSet.getString("order_no");
11???????System.out.println(orderNo);
12????}
13
14????preparedStatement.close();
15????connection.close();
16}
datasource 需要提供根據分片結果獲取對應的數據源的datasource，返回的connection應該是定制后的 connection，因為在執行 sql 前還無法知道是哪個庫哪個表，所以只能返回一個邏輯意義上的 connection。
哈希 connection 定制的 connection，需要實現獲取 statement，執行 sql 關閉。設置auto commit 等方法，在執行 sql 和獲取 statement 的時候應該進行路由找到物理表后 在執行操作。由于該 connection 是邏輯意義上的，針對關閉，設置 auto commit 等需要將關聯的多個物理 connection 一起設置。
statement 定制化的 statement，由于和 connection 都提供了執行 sql 的方法，所以我們可以將執行 sql 都交給一個執行器執行，connection 和 statement 中都通過這個執行器執行sql。在執行器重解析 sql 獲取物理連接，結果集處理等操作。
resultset resultset 是一個迭代器，遍歷的時候數據源由數據庫提供，但我們在某些有排序和 limit 的查詢中，可能迭代器直接在內存中遍歷數據。
SQL解析
sql 解析一般借助 druid 框架里面的 SQLStatementParser 類。解析好的數據都在 SQLStatement 中，當然有條件的可以自己研究 SQL 解析，不過可能工作量有點大。
解析出 sql 類型，目前生成環境主要還是4中 sql 類型： SELECT? DELETE? UPDATE INSERT ，目前是直接解析 sql 是否以上面4個單詞開頭即可，不區分大小寫。
insert 類型需要區分，是否是批量插入，解析出 insert 插入的列的字段名稱和對應的值，如果插入的列中不包含分片字段，將無法定位到具體插入到哪個物理表，此時應該拋出異常。
delete 和 update 都需要解析 where 后的條件，根據查詢條件里的字段，嘗試路由到指定的物理表，注意此時可能會出現 where 條件里面 分片字段可能是一個范圍，或者分片字段存在多個限制。
select 和其他類型不同的是，返回結果是一個 list，而其他三種 sql 直接返回狀態和影響行數即可。同時 select 可能出現關聯查詢，以及針對查詢結果進行篩選的操作，例如where 條件中除了普通的判斷表達式，還可能存在 limit，order by，group by，having等，select 的結果中也可能包含聚合統計等信息，例如 sum，count，max，min，avg等，這些都需要解析出來方便后續結果集的處理，后續重新生成 sql 主要是替換邏輯表名為物理表名，并獲取對應的數據庫物理連接。
針對 avg 這種操作，如果涉及查詢多個物理表的，可能需要改寫 sql 去查詢 sum 和count 的數據或者 avg 和 count 的數據，改寫需要注意可能原 sql 里面已經包含了count，sum等操作了。
分片路由算法
分片算法，主要通過一個表達式，從分片字段對應的值獲取到分片結果，可以提供簡單地 EL表達式，就可以實現從值中截取某一段作為分表數據，也可以提供通用的一致性哈希算法的實現，應用方只需要在 xml 或者注解中配置即可，以下為一致性哈希在銅板街的實現。
1/** 2?*?最大真實節點數 3?*/4private?int?max;
5
6/** 7?*?真實節點的數量 8?*/
9private?int?current;
10
11private?int[]?bucket;
12
13private?Set?suffixSet;
14
15public?void?init()??{
16????bucket?=?new?int[max];
17????suffixSet?=?new?TreeSet();
18
19????int?length?=?max?/?current;
20????int?lengthIndex?=?0;
21
22????int?suffix?=?0;
23
24????for?(int?i?=?0;?i?25????????bucket[i]?=?suffix;
26????????lengthIndex?++;
27????????suffixSet.add(suffix);
28????????if?(lengthIndex?==?length){
29????????????lengthIndex?=?0;
30????????????suffix?=?i?+?1;
31????????}
32????}
33}
34
35public?VirtualModFunction(int?max,?int?current){
36????this.current?=?current;
37????this.max?=?max;
38????this.init();
39}
40
41
42@Override43public?Integer?execute(String?columnValue,?Map?extension)?{
44????return?bucket[((Long)?(Long.valueOf(columnValue)?%?max)).intValue()];
45}?
這里也可以順帶做一下讀寫分離，配置一些讀操作路由到哪個實例，寫操作路由到哪個實例，并且做到負載均衡，對應用層透明。
結果集合并
如果需要在多個物理表上執行查詢，則需要對結果集進行合并處理，此處需要注意返回是一個迭代器 resultset。
統計類 針對 sum count，max，min 只需要將每個結果集的返回結果在做一個 max 和min，count 和 sum 直接相加即可，針對 avg 需要通過上面改寫的 sql 獲取 sum 和count 然后相除計算平均值。
排序類大部分的排序都伴隨著 limit 限制查詢條數。例如返回結果需要查詢最近的2000條記錄，并且根據創建時間倒序排序，根據路由結果需要查詢所有的物理表，假設是4張表，如果此時4張表的數據沒有時間上的排序關系，則需要每張表都查詢2000條記錄，并且按照創建時間倒序排列，現在要做的就是從4個已經排序好的鏈表，每個鏈表最多2000條數據，重新排序，選擇2000條時間最近的，我們可以通過插入排序的算法，每次分別從每個鏈表中取出時間最大的一個，在新的結果集里找到位置并插入，直到結果集中存在2000條記錄，但是這里可能存在一個問題，如果某一個鏈表的數據普遍比其他鏈表數據偏大，這樣每個鏈表取500條數據肯定排序不準確，所以我們還需要保證當前所有鏈表中剩下的數據的最大值比新結果集中的數據小。 而實際上業務層的需求可能并不是僅僅取出2000條數據，而是要遍歷所有的數據，這種要遍歷所有數據集的情況，建議在業務層控制一張表一張表的遍歷，如果每次都要去每張表中查詢在排序嚴重影響效率，如果在應用層控制，我們在后面在聊。
聚合類 group by 應用層需要盡量避免這種操作，這些需求最好能交給搜索引擎和數據分析平臺進行，但是作為一個中間件，對于group by 這種我們經常需要統計數據的類型還是應該盡量支持的，目前的做法是 和統計類處理類似，針對各個子集進行合并處理。
優化
以上流程基本可以實現一個簡易版本的數據庫分庫分表中間件，為了讓我們的中間件更方便開發者使用，為日常工作提供更多地遍歷性，我們還可以從以下幾點做優化。
和 spring 集成
針對哪些表需要進行分片，分片規則等，這些需要定制化的配置，我們可以在程序里面手工編碼，但是這樣業務層又耦合了分表的邏輯，我們可以借助 spring 的配置文件，直接將 xml 里的內容映射成對應的 bean 實例。
我們首先要設計好對應的配置文件的格式，有哪些節點，每個節點包含哪些屬性，然后設計自己命名空間，和對應的 XSD 校驗文件，XSD 文件放在 META-INF下。
編寫 NamespaceHandlerSupport 類，注冊每個節點元素對應的解析器
2
3????//com.alibaba.dubbo.config.spring.schema.DubboNamespaceHandler
4????@Override
5????public?void?init()?{
6????????registerBeanDefinitionParser("table",?new?BaymaxBeanDefinitionParser(TableConfig.class,?false));
7????????registerBeanDefinitionParser("context",?new?BaymaxBeanDefinitionParser(BaymaxSpringContext.class,?false));
8????????registerBeanDefinitionParser("process",?new?BaymaxBeanDefinitionParser(ColumnProcess.class,?false));
9????}
10
11}
在 META-INF 文件中增加配置文件 spring.handlers 中配置 spring遇到某個namespace下的節點后 通過哪個解析器解析，最終返回配置實例。
1http://baymax.tongbanjie.com/schema/baymax-3.0=com.tongbanjie.baymax.spring.BaymaxNamespaceHandler在 META-INF 文件中增加配置文件 spring.schema 中配置 spring遇到某個namespace下的節點后 通過哪個XSD文件進行校驗。
1http://baymax.tongbanjie.com/schema/baymax-3.0.xsd=META-INF/baymax-3.0.xsd可以借助ListableBeanFactory的getBeansOfType(Class?clazz) 來獲取某個class類型的所有實例,從而獲得所有的配置信息。
當然也可以通過自定義注解進行申明，這種方式我們可以借助 BeanPostProcessor 的時候判斷類上是否包含指定的注解，但是這種方式比較笨重，而且所加注解的類必須在spring 容器管理中，也可以借助 ClassPathScanningCandidateComponentProvider 和 AnnotationTypeFilter 實現，或者直接通過 classloader 掃描指定的包路徑。
如何支持分布式事務
由于框架本身通過定制 JDBC 協議實現，雖然最終執行 sql 的是通過原生 JDBC，但是對上層應用透明，同時也對上層基于 JDBC 實現的事物透明，spring 的事物管理器可以直接使用。
我們考慮下以下問題,如果我們針對多張表在一個線程池內并發的區執行 sql，然后在合并結果，這是否會影響 spring的 事物管理器?
首先 spring 的聲明式事物是通過 aop 在切面做增強，事物開始先獲取 connection 并設置 setAutocommit 為 fasle，事物結束調用 connection 進行 commit 或者 rollback，通過 threadlocal 保存事物上下文和所使用的 connection 來保證事物內多個 sql共用一個 connection 操作。但是如果我們在解析 sql 后發現要執行多條 sql 語句，我們通過線程池并發執行，然后等所有的結果返回后進行合并，(這里先不考慮，多個 sql 可能需要在不同的數據庫實例上執行)，雖然通過線程池將導致 threadlocal 失效，但是我們在 threadlocal 維護的是我們自己定制的 connection，并不是原生的 JDBC 里的 connection ，而且這里并發執行并不會讓事物處理器沒辦法判斷是否所有的線程都已經結束，然后進行 commit 或者 rollback 。因為這里的線程池是在我們定制的 connection 執行 sql 過程中運用的，肯定會等到所有線程處理結束后并且合并數據集才會返回。所以在本地事物層面，通過定制化 JDBC 可以做到對上層事物透明。
如果我們進行了分庫，同一個表可能在多個數據庫實例里，這種如果要對不同實例里的表進行更新，那么將無法在使用本地事物，這里我們不在討論分布式事物的實現，由于二階段提交的各種缺點，目前很少有公司會基于二階段做分布式事物，所以我們的中間件也可以根據自己的具體業務考慮是否要實現 XA，目前銅板街大部分分布式事物需求都是通過基于 TCC 的事物補償做的，這種方式對業務冪等要求較高，同時要基于業務層實現回滾邏輯。
提供一個通用發號器
為什么要提供一個發號器，我們在單表的時候，可能會用到數據庫的自增ID，但當分成多表后，每個表都進行單獨的ID自增，這樣一個邏輯表內的ID 就會出現重復。
我們可以提供一個基于邏輯表自增的主鍵ID 獲取方式，如果沒有分庫只分表，可以在數據庫中增加一個表維護每張邏輯表對應的自增ID。每次需要獲取ID 的時候都先查詢這個標當前的ID 然后加一返回，然后在寫入數據庫，為了并發獲取的情況，我們可以采用樂觀鎖，類似于CAS，update的時候傳人以前的ID。如果被人修改過則重新獲取，當然我們也可以一次性獲取一批ID例如一次獲取100個，等這100個用完了在重新獲取，為了避免這100個還沒用完，程序正?；蚍钦Ｍ顺?#xff0c;在獲取這100個值的時候就將數據庫通過CAS更新為已經獲取了100個值之和的值。
不推薦用 UUID，無序，太長占內存影響索引效果，不攜帶任何業務含義。
借助 ZOOKEEPER 的 zone 的版本號來做序列號。
借助 REDIS 的 INCR 命令，進行自增，每臺 redis 設置不同的初始值，但是設置相同的歩長。
1A：1,6,11,16,212B：2,7,12,17,22
3C：3,8,13,18,23
4D：4,9,14,19,24
5E：5,10,15,20,25
snowflake算法：其核心思想是：使用41bit作為毫秒數，10bit作為機器的ID(5個bit是數據中心，5個bit的機器ID)，12bit作為毫秒內的流水號(意味著每個節點在每毫秒可以產生 4096 個 ID)。
銅板街目前所使用的訂單號規則： - 15位時間戳，4位自增序列，2位區分訂單類型，7位機器ID，2位分庫后綴，2位分表后綴 共32位 - 7位機器ID 通過IP來獲取 - 15位時間戳精確到毫秒，4位自增序列，意味著單JVM1毫秒可以生成9999個訂單 。
圖6
最后4位可以方便的根據訂單號定位到物理表，這里需要注意分庫分表如果是根據一致性哈希算法，這個地方最好存最大值， 例如 用戶id % 64 取余 最多可以分64張表，而目前可能用不到這么多，每相鄰4個數字分配到一張表，共16張表，既 userID % 64 / 4 * 4 ,而這個地方存儲 userID % 64 即可，不必存最終分表的結果，這種方式方便后續做擴容，可能分表的結果變更了，但是訂單號卻無法進行變更。
2public?String?routeDbByUserId(String?userId)?{
3????Assert.hasLength(userId,?"用戶ID不能為空");
4
5????Integer?userIdInteger?=?null;
6????try?{
7????????userIdInteger?=?Integer.parseInt(userId);
8????}?catch?(Exception?ex)?{
9????????logger.error("解析用戶ID為整數失敗"?+?userId,?ex);
10????????throw?new?RuntimeException("解析用戶ID為整數失敗");
11????}
12
13????//根據路由規則確定,具體在哪個庫哪個表?例如根據分庫公式最終結果在0到63之間??如果要分兩個庫?mod為32?分1個庫mod為64?分16個庫?mod為4
14????//規律為?64?=?mod?*?(最終的分庫數或分表數)
15????int?mod?=?orderSplitConfig.getDbSegment();
16
17????Integer?dbSuffixInt?=?userIdInteger?/?64?%?64?/?mod?*?mod?;
18
19????return?StringUtils.leftPad(String.valueOf(dbSuffixInt),??2,?'0');
20}
21
22
23@Override
24public?String?routeTableByUserId(String?userId)?{
25
26????Assert.hasLength(userId,?"用戶ID不能為空");
27
28????Integer?userIdInteger?=?null;
29????try?{
30????????userIdInteger?=?Integer.parseInt(userId);
31????}?catch?(Exception?ex)?{
32????????logger.error("解析用戶ID為整數失敗"?+?userId,?ex);
33????????throw?new?RuntimeException("解析用戶ID為整數失敗");
34????}
35
36????//根據路由規則確定,具體在哪個庫哪個表?例如根據分表公式最終結果在0到63之間??如果要分兩個庫?mod為32?分1個庫mod為64?分16個庫?mod為4
37????//規律為?64?=?mod?*?(最終的分庫數或分表數)
38????int?mod?=?orderSplitConfig.getTableSegment();
39
40????Integer?tableSuffixInt?=?userIdInteger?%?64?/?mod?*?mod;
41
42????return?StringUtils.leftPad(?String.valueOf(tableSuffixInt),??2,?'0');
43}????
如何實現跨表遍歷
如果業務需求是遍歷所有滿足條件的數據，而不是只是為了取某種條件下前面一批數據，這種建議在應用層實現，一張表一張表的遍歷，每次查詢結果返回下一次查詢的起始位置和物理表名，查詢的時候建議根據 大于或小于某一個 ID 進行分頁，不要 limit500,500這種，以下為銅板街的實現方式。
1public?List?select(String?tableName,?SelectorParam?selectorParam,?E?realQueryParam)?{ 2 3????List?list?=?new?ArrayList(); 4 5????//?定位到某張表 6????String?suffix?=?partitionManager.getCurrentSuffix(tableName,?selectorParam.getLocationNo()); 7 8????int?originalSize?=?selectorParam.getLimit(); 910????while?(true)?{1112????????List?ts?=?this.queryByParam(realQueryParam,?selectorParam,?suffix);1314????????if?(!CollectionUtils.isEmpty(ts))?{15????????????list.addAll(ts);16????????}1718????????if?(list.size()?==?originalSize)?{19????????????break;20????????}2122????????suffix?=?partitionManager.getNextSuffix(tableName,?suffix);2324????????if?(StringUtils.isEmpty(suffix))?{25????????????break;26????????}2728????????//?查詢下一張表?不需要定位單號?而且也只需要查剩下的size即可29????????selectorParam.setLimit(originalSize?-?list.size());30????????selectorParam.setLocationNo(null);31????}3233????return?list;34}提供一個擴容工具和管理控制臺做配置可視化和監控
監控可以借助 druid,也可以在定制的 JDBC 層自己做埋點，將數據以報表的形式進行展示，也可以針對特定的監控指標進行配置，例如執行次數，執行時間大于某個指定時間。
管理控制臺，由于目前配置是在應用層，當然也可以把配置獨立出來放在獨立的服務器上，由于分片配置基本上無法在線修改，每次修改可能都伴隨著數據遷移，所以基本上只能做展示，但是分表后我們在測試環境執行 sql 去進行邏輯查詢的時候，傳統的 sql 工具無法幫忙做到自動路由，這樣我們每次查詢可能都需要手工計算下分片結果，或者要連續寫好幾個 sql 之后在聚合，通過這個管理控制臺我們就可以直接根據邏輯表名寫 sql，這樣我們在測試環境或者在線上核對數據的時候，就提高了效率。
擴容工具，笨辦法只能先從老表查詢在 insert 到新表，等到新表數據完全同步完后，在切換到新的切片規則，所以我們設計分片算法的時候，需要考慮到后面擴容，例如一致性哈希就需要遷移一半的數據(擴容一倍的話) 數據遷移如果出現故障，那將是個災難，如果我們要在不停機的情況下完成擴容，可以通過配置文件按以下流程來。
準備階段.將截至到某一刻的歷史表數據同步到新表 例如截至2017年10月1日之前的歷史數據，這些歷史數據最好不會在被修改；
階段一.訪問老表，寫入老表；
階段二.訪問老表，寫入老表同時寫入新表 (插入和修改)；
階段三.將10月1日到首次寫入新表之間的數據同步到新表 需要保證此時被遷移的數據全部都是終態；
階段四.訪問新表，寫入老表和新表；
階段五.訪問新表，寫入新表。
以上流程適用于，訂單這種歷史數據在達到終態后將不會在被修改，如果歷史數據也可能被修改，則可能需要停機，或者通過 canel 進行數據同步。
相關熱文
帶你了解JavaScript的運行機制—Event Loop
安卓平臺Flutter啟動過程全解析
海報分享功能實現詳解
Android客戶端項目組件化實踐
iOS組件化實踐
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的中间表增加额外字段_如何定制分表中间件的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python 粒子滤波目标追踪_Pyth
- 下一篇： ajax请求_重复的ajax请求让人很受