作者：京東物流 張廣治
1 背景
傳統的將資料集中存盤至單一資料節點的解決方案，在性能和可用性方面已經難于滿足海量資料的場景，系統最大的瓶頸在于單個節點讀寫性能，許多的資源受到單機的限制，例如連接數、網路IO、磁盤IO等，從而導致它的并發能力不高，對于高并發的要求不滿足，
每到月初國際財務系統壓力巨大，因為月初有大量補全任務，重算、計算任務、賬單生成任務、推送集成等都要趕在月初1號完成，顯然我們需要一個支持高性能、高并發的方案來解決我們的問題，
2 我們的目標
- 支持每月接單量一億以上，
- 一億的單量補全，計算，生成賬單在24小時內完成（支持前面說的月初大資料量計算的場景）
3 資料分配規則
現實世界中，每一個資源都有其提供服務能力的上限，當某一個資源達到最大上限后就無法及時處理溢位的需求，這樣就需要使用多個資源同時提供服務來滿足大量的任務，當使用了多個資源來提供服務時，最為關鍵的是如何讓每一個資源比較均勻的承擔壓力，而不至于其中的某些資源壓力過大，所以分配規則就變得非常重要，
制定分配規則：要根據查詢和存盤的場景，一般按照型別、時間、城市、區域等作為分片鍵，
財務系統的租戶以業務線為單位，缺點為拆分的粒度太大，不能實作打散資料的目的，所以不適合做為分片鍵，事件定義作為分片鍵，缺點是非常不均勻，目前2C進口清關，一個事件，每月有一千多萬資料，鯤鵬的事件，每月單量很少，如果按照事件定義拆分，會導致資料極度傾斜，
目前最適合作為分片鍵的就是時間，因為系統中計算，賬單，匯總，都是基于時間的，所以時間非常適合做分片鍵，適合使用月、周、作為Range的周期，目前使用的就是時間磁區，但只按照時間磁區顯然已經不能滿足我們的需求了，
經過篩選，理論上最適合的磁區鍵就剩下時間和收付款物件了，
最終我們決定使用收付款物件分庫，時間作為表磁區，
資料拆分前結構（圖一）：
資料水平拆分后結構（圖二）：
分配規則
(payer.toUpperCase()+"_"+payee.toUpperCase()).hashCode().abs()%128
收款物件大寫加分隔符加付款物件大寫，取HASH值的絕對值模分庫數量
重要：payer和payee字母統一大寫，因為大小寫不統一，會導致HASH值不一致，最終導致路由到不同的庫，
4 讀寫分離一主多從
4.1ShardingSphere對讀寫分離的解釋
對于同一時刻有大量并發讀操作和較少寫操作型別的資料來說，將資料庫拆分為主庫和從庫，主庫負責處理事務性的增刪改操作，從庫負責處理查詢操作，能夠有效的避免由資料更新導致的行鎖，使得整個系統的查詢性能得到極大的改善，
通過一主多從的配置方式，可以將查詢請求均勻的分散到多個資料副本，能夠進一步的提升系統的處理能力， 使用多主多從的方式，不但能夠提升系統的吞吐量，還能夠提升系統的可用性，可以達到在任何一個資料庫宕機，甚至磁盤物理損壞的情況下仍然不影響系統的正常運行，
把資料量大的大表進行資料分片，其余大量并發讀操作且寫入小的資料進行讀寫分離，如（圖三）：
左側為主從結構，右側為資料分片
4.2 讀寫分離+資料分片實戰
當我們實際使用sharding進行讀寫分離+資料分片時遇到了一個很大的問題，官網檔案中的實作方式只適合分庫和從庫在一起時的場景如（圖四）
而我們的場景為（圖三）所示，從庫和分庫時徹底分開的，參考官網的實作方法如下：
https://shardingsphere.apache.org/document/4.1.1/cn/manual/sharding-jdbc/configuration/config-spring-boot/#資料分片--讀寫分離
官網給出的讀寫分離+資料分片方案不能配置
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';
3.在classpath中增加seata.conf
client {
application.id = example ## 應用唯一id
transaction.service.group = my_test_tx_group ## 所屬事務組
}
6.3 Sharding-Jdbc默認提供弱XA事務
官方說明：
完全支持非跨庫事務，例如：僅分表，或分庫但是路由的結果在單庫中，
完全支持因邏輯例外導致的跨庫事務，例如：同一事務中，跨兩個庫更新，更新完畢后，拋出空指標，則兩個庫的內容都能回滾，
不支持因網路、硬體例外導致的跨庫事務，例如：同一事務中，跨兩個庫更新，更新完畢后、未提交之前，第一個庫死機，則只有第二個庫資料提交，
6.4 分布式事務場景
1.保存場景
推薦使用第三種弱XA事務，盡量設計時避免跨庫事務，目前設計為事件和事件資料為同庫（分庫時，將一個線索號的事件和事件資料HASH進入同一個分庫），盡量避免跨庫事務，
事件和計費結果本身設計為異步，非同一事務，所以事件和對應的結果不涉及跨庫事務，
保存多個計費結果，每次保存都屬于一個事件，一個事件的計費結果都屬于一個收付款物件，天然同庫，
弱XA事務的性能最佳，
2.更新場景
對一些根據ID IN的更新場景，根據收付款物件分組執行，可以避免在所有分庫執行更新，
3.洗掉場景
無，目前都是邏輯洗掉，實際為更新，
7 總結
1.推薦使用Sharding-Sphere進行分庫，分表可以考慮使用MYSQL磁區表，對于研發來講完全是透明的，可以規避JOIN\分布式事務等問題，（磁區表需要為磁區鍵+ID建立了一個聯合索引）MYSQL磁區得到了大量的實踐印證，沒有BUG，包括我在新計費初期，一直堅持推動使用的分表方案，不會引起一些難以發現的問題，在同庫同磁盤下性能與分表相當，
2.對于同一時刻有大量并發讀操作和較少寫操作型別的資料來說，適合使用讀寫分離，增加多個讀庫，緩解主庫壓力，要注意的是必須讀主庫的場景使用SeekMaster注解來實作，
3.資料分庫選擇合適的分片鍵非常重要，要根據業務需求選擇好分庫鍵，盡力避免資料傾斜，資料不均勻是目前資料拆分的一個共同問題，不可能實作資料的完全均勻；當查詢條件沒有分庫鍵時會遍歷所有分庫，查詢盡量帶上分庫鍵，
4.在我們使用中間件時，不要只看官網解釋，要多做測驗，用實際來驗證，有的時候官網解釋話術可能存在歧義或表達不夠全面的地方，分析原始碼和實際測驗可以清晰的獲得想要的結果，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/544156.html
標籤：其他