作者：京東物流 張廣治
1 背景
傳統的將數據集中存儲至單一數據節點的解決方案，在性能和可用性方面已經難于滿足海量數據的場景，系統最大的瓶頸在于單個節點讀寫性能，許多的資源受到單機的限制，例如連接數、網絡IO、磁盤IO等，從而導致它的并發能力不高，對于高并發的要求不滿足。
每到月初國際財務系統壓力巨大，因為月初有大量補全任務，重算、計算任務、賬單生成任務、推送集成等都要趕在月初1號完成，顯然我們需要一個支持高性能、高并發的方案來解決我們的問題。
2 我們的目標
- 支持每月接單量一億以上。
- 一億的單量補全，計算，生成賬單在24小時內完成（支持前面說的月初大數據量計算的場景）
3 數據分配規則
現實世界中，每一個資源都有其提供服務能力的上限，當某一個資源達到最大上限后就無法及時處理溢出的需求，這樣就需要使用多個資源同時提供服務來滿足大量的任務。當使用了多個資源來提供服務時，最為關鍵的是如何讓每一個資源比較均勻的承擔壓力，而不至于其中的某些資源壓力過大，所以分配規則就變得非常重要。
制定分配規則：要根據查詢和存儲的場景，一般按照類型、時間、城市、區域等作為分片鍵。
財務系統的租戶以業務線為單位，缺點為拆分的粒度太大，不能實現打散數據的目的，所以不適合做為分片鍵，事件定義作為分片鍵，缺點是非常不均勻，目前2C進口清關，一個事件，每月有一千多萬數據，鯤鵬的事件，每月單量很少，如果按照事件定義拆分，會導致數據極度傾斜。
目前最適合作為分片鍵的就是時間，因為系統中計算，賬單，匯總，都是基于時間的，所以時間非常適合做分片鍵，適合使用月、周、作為Range的周期。目前使用的就是時間分區，但只按照時間分區顯然已經不能滿足我們的需求了。
經過篩選，理論上最適合的分區鍵就剩下時間和收付款對象了。
最終我們決定使用收付款對象分庫，時間作為表分區。
數據拆分前結構（圖一）：
數據水平拆分后結構（圖二）：
分配規則
(payer.toUpperCase()+"_"+payee.toUpperCase()).hashCode().abs()%128
收款對象大寫加分隔符加付款對象大寫，取HASH值的絕對值模分庫數量
重要：payer和payee字母統一大寫，因為大小寫不統一，會導致HASH值不一致，最終導致路由到不同的庫。
4 讀寫分離一主多從
4.1 ShardingSphere對讀寫分離的解釋
對于同一時刻有大量并發讀操作和較少寫操作類型的數據來說，將數據庫拆分為主庫和從庫，主庫負責處理事務性的增刪改操作，從庫負責處理查詢操作，能夠有效的避免由數據更新導致的行鎖，使得整個系統的查詢性能得到極大的改善。
通過一主多從的配置方式，可以將查詢請求均勻的分散到多個數據副本，能夠進一步的提升系統的處理能力。 使用多主多從的方式，不但能夠提升系統的吞吐量，還能夠提升系統的可用性，可以達到在任何一個數據庫宕機，甚至磁盤物理損壞的情況下仍然不影響系統的正常運行。
把數據量大的大表進行數據分片，其余大量并發讀操作且寫入小的數據進行讀寫分離，如（圖三）：
左側為主從結構，右側為數據分片
4.2 讀寫分離+數據分片實戰
當我們實際使用sharding進行讀寫分離+數據分片時遇到了一個很大的問題，官網文檔中的實現方式只適合分庫和從庫在一起時的場景如（圖四）
而我們的場景為（圖三）所示，從庫和分庫時徹底分開的，參考官網的實現方法如下：
??https://shardingsphere.apache.org/document/4.1.1/cn/manual/sharding-jdbc/configuration/config-spring-boot/#%E6%95%B0%E6%8D%AE%E5%88%86%E7%89%87--%E8%AF%BB%E5%86%99%E5%88%86%E7%A6%BB??
官網給出的讀寫分離+數據分片方案不能配置
spring.shardingsphere.sharding.default-data-source-name默認數據源，如果配置了，所有讀操作將全部指向主庫，無法達到讀寫分離的目的。
當我們困擾在讀從庫的查詢會被輪詢到分庫中，我們實際的場景從庫和分庫是分離的，分庫中根本就不存在從庫中的表。此問題困擾了我近兩天的時間，我閱讀源碼發現
spring.shardingsphere.sharding.default-data-source-name可以被賦值一個DataNodeGroup，不僅僅支持配置datasourceName，sharding源碼如下圖：
由此spring.shardingsphere.sharding.default-data-source-name配置為讀寫分離的groupname1，問題解決
從庫和分庫不在一起的場景下，讀寫分離+數據分配的配置如下：
#數據源名稱
spring.shardingsphere.datasource.names= defaultmaster,ds0,ds1,ds2,ds3,ds4,ds5,ds6,ds7,ds8,ds9,ds10,ds11,ds12,ds13,ds14,ds15,ds16,ds17,ds18,ds19,ds20,ds21,ds22,ds23,ds24,ds25,ds26,ds27,ds28,ds29,ds30,ds31,slave0,slave1
#未配置分片規則的表將通過默認數據源定位，注意值必須配置為讀寫分離的分組名稱groupname1
spring.shardingsphere.sharding.default-data-source-name=groupname1
#主庫
spring.shardingsphere.datasource.defaultmaster.jdbc-url=jdbc:mysql:
spring.shardingsphere.datasource.defaultmaster.type= com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.defaultmaster.driver-class-name= com.mysql.jdbc.Driver
#分庫ds0
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql:
spring.shardingsphere.datasource.ds0.type= com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds0.driver-class-name= com.mysql.jdbc.Driver
#從庫slave0
spring.shardingsphere.datasource.slave0.jdbc-url=jdbc:mysql:
spring.shardingsphere.datasource.slave0.type= com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave0.driver-class-name= com.mysql.jdbc.Driver
#從庫slave1
spring.shardingsphere.datasource.slave1.jdbc-url=jdbc:mysql:
spring.shardingsphere.datasource.slave1.type= com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave1.driver-class-name= com.mysql.jdbc.Driver
#由數據源名 + 表名組成，以小數點分隔。多個表以逗號分隔，支持inline表達式。缺省表示使用已知數據源與邏輯表名稱生成數據節點，用于廣播表（即每個庫中都需要一個同樣的表用于關聯查詢，多為字典表）或只分庫不分表且所有庫的表結構完全一致的情況
spring.shardingsphere.sharding.tables.incident_ar.actual-data-nodes=ds$->{0..127}.incident_ar
#行表達式分片策略 分庫策略，缺省表示使用默認分庫策略
spring.shardingsphere.sharding.tables.incident_ar.database-strategy.inline.sharding-column= dept_no
#分片算法行表達式，需符合groovy語法
spring.shardingsphere.sharding.tables.incident_ar.database-strategy.inline.algorithm-expression=ds$->{dept_no.toUpperCase().hashCode().abs() % 128}
#讀寫分離配置
spring.shardingsphere.sharding.master-slave-rules.groupname1.master-data-source-name=defaultmaster
spring.shardingsphere.sharding.master-slave-rules.groupname1.slave-data-source-names[0]=slave0
spring.shardingsphere.sharding.master-slave-rules.groupname1.slave-data-source-names[1]=slave1
spring.shardingsphere.sharding.master-slave-rules.groupname1.load-balance-algorithm-type=round_robin
可以看到讀操作可以被均勻的路由到slave0、slave1中，分片的讀會被分配到ds0，ds1中如下圖:
4.3 實現自己的讀寫分離負載均衡算法
Sharding提供了SPI形式的接口
org.apache.shardingsphere.spi.masterslave.MasterSlaveLoadBalanceAlgorithm實現讀寫分離多個從的具體負載均衡規則，代碼如下：
import lombok.Getter;
import lombok.RequiredArgsConstructor;
import lombok.Setter;
import org.apache.shardingsphere.spi.masterslave.MasterSlaveLoadBalanceAlgorithm;
import org.springframework.stereotype.Component;
import java.util.List;
import java.util.Properties;
@Component
@Getter
@Setter
@RequiredArgsConstructor
public final class LoadAlgorithm implements MasterSlaveLoadBalanceAlgorithm {
private Properties properties = new Properties();
@Override
public String getType() {return "loadBalance";}
@Override
public String getDataSource(final String name, final String masterDataSourceName, final List<String> slaveDataSourceNames) {
//自己的負載均衡規則
return slaveDataSourceNames.get(0);
RoundRobinMasterSlaveLoadBalanceAlgorithm 實現為所有從輪詢負載
RandomMasterSlaveLoadBalanceAlgorithm 實現為所有從隨機負載均衡
4.4 關于某些場景下必須讀主庫的解決方案
某些場景比如分布式場景下寫入馬上讀取的場景，可以使用hint方式進行強制讀取主庫，Sharding源碼使用ThreadLocal實現強制路由標記。
下面封裝了一個注解可以直接使用，代碼如下：
@Documented
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface SeekMaster {
}
import lombok.extern.slf4j.Slf4j;
import org.apache.shardingsphere.api.hint.HintManager;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
/**
* ShardingSphere >讀寫分離自定義注解>用于實現讀寫分離時>需要強制讀主庫的場景（注解實現類）
*
* @author zhangguangzhi1
**/
@Slf4j
@Aspect
@Component
public class SeekMasterAnnotation {
@Around("@annotation(seekMaster)")
public Object doInterceptor(ProceedingJoinPoint joinPoint, SeekMaster seekMaster) throws Throwable {
Object object = null;
Throwable t = null;
try {
HintManager.getInstance().setMasterRouteOnly();
log.info("強制查詢主庫");
object = joinPoint.proceed();
} catch (Throwable throwable) {
t = throwable;
} finally {
HintManager.clear();
if (t != null) {
throw t;
}
}
return object;
使用時方法上打SeekMaster注解即可，方法下的所有讀操作將自動路由到主庫中，方法外的所有查詢還是讀取從庫，如下圖：
4.5 關于官網對讀寫分離描述不夠明確的補充說明
版本4.1.1
經實踐補充說明為：
同一線程且同一數據庫連接且一個事務中，如有寫入操作，以后的讀操作均從主庫讀取，只限存在寫入的表，沒有寫入的表，事務中的查詢會繼續路由至從庫中，用于保證數據一致性。
5 關于分庫的JOIN操作
方法1
使用default-data-source-name配置默認庫，即沒有配置數據分片策略的表都會使用默認庫。默認庫中表禁止與拆分表進行JOIN操作，此處需要做一些改造，目前系統有一些JOIN操作。（推薦使用此方法）
方法2
使用全局表，廣播表，讓128個庫中冗余基礎庫中的表，并實時改變。
方法3
分庫表中冗余需要JOIN表中的字段，可以解決JOIN問題，此方案單個表字段會增加。
6 分布式事務
6.1 XA事務管理器參數配置
XA是由X/Open組織提出的分布式事務的規范。 XA規范主要定義了(全局)事務管理器(TM)和(局 部)資源管理器(RM)之間的接口。主流的關系型 數據庫產品都是實現了XA接口的。
分段提交
XA需要兩階段提交: prepare 和 commit.
第一階段為 準備（prepare）階段。即所有的參與者準備執行事務并鎖住需要的資源。參與者ready時，向transaction manager報告已準備就緒。
第二階段為提交階段（commit）。當transaction manager確認所有參與者都ready后，向所有參與者發送commit命令。
ShardingSphere默認的XA事務管理器為Atomikos，在項目的logs目錄中會生成xa_tx.log, 這是XA崩潰恢復時所需的日志，請勿刪除。
6.2 BASE柔性事務管理器（SEATA-AT配置）
Seata 是一款開源的分布式事務解決方案，提供簡單易用的分布式事務服務。隨著業務的快速發展，應用單體架構暴露出代碼可維護性差，容錯率低，測試難度大，敏捷交付能力差等諸多問題，微服務應運而生。微服務的誕生一方面解決了上述問題，但是另一方面卻引入新的問題，其中主要問題之一就是如何保證微服務間的業務數據一致性。Seata 注冊配置服務中心均使用 Nacos。Seata 0.2.1+ 開始支持 Nacos 注冊配置服務中心。
- 按照seata-work-shop中的步驟，下載并啟動seata server。
- 在每一個分片數據庫實例中執創建undo_log表（以MySQL為例）
CREATE TABLE IF NOT EXISTS `undo_log`
(
`id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 'increment id',
`branch_id` BIGINT(20) NOT NULL COMMENT 'branch transaction id',
`xid` VARCHAR(100) NOT NULL COMMENT 'global transaction id',
`context` VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
`rollback_info` LONGBLOB NOT NULL COMMENT 'rollback info',
`log_status` INT(11) NOT NULL COMMENT '0:normal status,1:defense status',
`log_created` DATETIME NOT NULL COMMENT 'create datetime',
`log_modified` DATETIME NOT NULL COMMENT 'modify datetime',
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
AUTO_INCREMENT = 1
DEFAULT CHARSET = utf8 COMMENT ='AT transaction mode undo table';
client {
application.id = example ## 應用唯一id
transaction.service.group = my_test_tx_group ## 所屬事務組
}6.3 Sharding-Jdbc默認提供弱XA事務
官方說明：
完全支持非跨庫事務，例如：僅分表，或分庫但是路由的結果在單庫中。
完全支持因邏輯異常導致的跨庫事務。例如：同一事務中，跨兩個庫更新。更新完畢后，拋出空指針，則兩個庫的內容都能回滾。
不支持因網絡、硬件異常導致的跨庫事務。例如：同一事務中，跨兩個庫更新，更新完畢后、未提交之前，第一個庫死機，則只有第二個庫數據提交。
6.4 分布式事務場景
推薦使用第三種弱XA事務，盡量設計時避免跨庫事務，目前設計為事件和事件數據為同庫（分庫時，將一個線索號的事件和事件數據HASH進入同一個分庫），盡量避免跨庫事務。
事件和計費結果本身設計為異步，非同一事務，所以事件和對應的結果不涉及跨庫事務。
保存多個計費結果，每次保存都屬于一個事件，一個事件的計費結果都屬于一個收付款對象，天然同庫。
弱XA事務的性能最佳。
對一些根據ID IN的更新場景，根據收付款對象分組執行，可以避免在所有分庫執行更新。
無，目前都是邏輯刪除，實際為更新。
7 總結
1.推薦使用Sharding-Sphere進行分庫，分表可以考慮使用MYSQL分區表，對于研發來講完全是透明的，可以規避JOIN\分布式事務等問題。（分區表需要為分區鍵+ID建立了一個聯合索引）MYSQL分區得到了大量的實踐印證，沒有BUG，包括我在新計費初期，一直堅持推動使用的分表方案，不會引起一些難以發現的問題，在同庫同磁盤下性能與分表相當。
2.對于同一時刻有大量并發讀操作和較少寫操作類型的數據來說，適合使用讀寫分離，增加多個讀庫，緩解主庫壓力，要注意的是必須讀主庫的場景使用SeekMaster注解來實現。
3.數據分庫選擇合適的分片鍵非常重要，要根據業務需求選擇好分庫鍵，盡力避免數據傾斜，數據不均勻是目前數據拆分的一個共同問題，不可能實現數據的完全均勻；當查詢條件沒有分庫鍵時會遍歷所有分庫，查詢盡量帶上分庫鍵。
4.在我們使用中間件時，不要只看官網解釋，要多做測試，用實際來驗證，有的時候官網解釋話術可能存在歧義或表達不夠全面的地方，分析源碼和實際測試可以清晰的獲得想要的結果。
