日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
國際財務系統(tǒng)基于ShardingSphere的數(shù)據(jù)分片和一主多從實踐

作者：京東物流 張廣治

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設,澄江企業(yè)網(wǎng)站建設,澄江品牌網(wǎng)站建設,網(wǎng)站定制,澄江網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,澄江網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

1 背景

傳統(tǒng)的將數(shù)據(jù)集中存儲至單一數(shù)據(jù)節(jié)點的解決方案，在性能和可用性方面已經(jīng)難于滿足海量數(shù)據(jù)的場景，系統(tǒng)最大的瓶頸在于單個節(jié)點讀寫性能，許多的資源受到單機的限制，例如連接數(shù)、網(wǎng)絡IO、磁盤IO等，從而導致它的并發(fā)能力不高，對于高并發(fā)的要求不滿足。

每到月初國際財務系統(tǒng)壓力巨大，因為月初有大量補全任務，重算、計算任務、賬單生成任務、推送集成等都要趕在月初1號完成，顯然我們需要一個支持高性能、高并發(fā)的方案來解決我們的問題。

2 我們的目標

  1. 支持每月接單量一億以上。
  2. 一億的單量補全，計算，生成賬單在24小時內完成（支持前面說的月初大數(shù)據(jù)量計算的場景）

3 數(shù)據(jù)分配規(guī)則

現(xiàn)實世界中，每一個資源都有其提供服務能力的上限，當某一個資源達到最大上限后就無法及時處理溢出的需求，這樣就需要使用多個資源同時提供服務來滿足大量的任務。當使用了多個資源來提供服務時，最為關鍵的是如何讓每一個資源比較均勻的承擔壓力，而不至于其中的某些資源壓力過大，所以分配規(guī)則就變得非常重要。

制定分配規(guī)則：要根據(jù)查詢和存儲的場景，一般按照類型、時間、城市、區(qū)域等作為分片鍵。

財務系統(tǒng)的租戶以業(yè)務線為單位，缺點為拆分的粒度太大，不能實現(xiàn)打散數(shù)據(jù)的目的，所以不適合做為分片鍵，事件定義作為分片鍵，缺點是非常不均勻，目前2C進口清關，一個事件，每月有一千多萬數(shù)據(jù)，鯤鵬的事件，每月單量很少，如果按照事件定義拆分，會導致數(shù)據(jù)極度傾斜。

目前最適合作為分片鍵的就是時間，因為系統(tǒng)中計算，賬單，匯總，都是基于時間的，所以時間非常適合做分片鍵，適合使用月、周、作為Range的周期。目前使用的就是時間分區(qū)，但只按照時間分區(qū)顯然已經(jīng)不能滿足我們的需求了。

經(jīng)過篩選，理論上最適合的分區(qū)鍵就剩下時間和收付款對象了。

最終我們決定使用收付款對象分庫，時間作為表分區(qū)。

數(shù)據(jù)拆分前結構（圖一）：

數(shù)據(jù)水平拆分后結構（圖二）：

分配規(guī)則

(payer.toUpperCase()+"_"+payee.toUpperCase()).hashCode().abs()%128

收款對象大寫加分隔符加付款對象大寫，取HASH值的絕對值模分庫數(shù)量

重要：payer和payee字母統(tǒng)一大寫，因為大小寫不統(tǒng)一，會導致HASH值不一致，最終導致路由到不同的庫。

4 讀寫分離一主多從

4.1 ShardingSphere對讀寫分離的解釋

對于同一時刻有大量并發(fā)讀操作和較少寫操作類型的數(shù)據(jù)來說，將數(shù)據(jù)庫拆分為主庫和從庫，主庫負責處理事務性的增刪改操作，從庫負責處理查詢操作，能夠有效的避免由數(shù)據(jù)更新導致的行鎖，使得整個系統(tǒng)的查詢性能得到極大的改善。

通過一主多從的配置方式，可以將查詢請求均勻的分散到多個數(shù)據(jù)副本，能夠進一步的提升系統(tǒng)的處理能力。 使用多主多從的方式，不但能夠提升系統(tǒng)的吞吐量，還能夠提升系統(tǒng)的可用性，可以達到在任何一個數(shù)據(jù)庫宕機，甚至磁盤物理損壞的情況下仍然不影響系統(tǒng)的正常運行。

把數(shù)據(jù)量大的大表進行數(shù)據(jù)分片，其余大量并發(fā)讀操作且寫入小的數(shù)據(jù)進行讀寫分離，如（圖三）：

左側為主從結構，右側為數(shù)據(jù)分片

4.2 讀寫分離+數(shù)據(jù)分片實戰(zhàn)

當我們實際使用sharding進行讀寫分離+數(shù)據(jù)分片時遇到了一個很大的問題，官網(wǎng)文檔中的實現(xiàn)方式只適合分庫和從庫在一起時的場景如（圖四）

而我們的場景為（圖三）所示，從庫和分庫時徹底分開的，參考官網(wǎng)的實現(xiàn)方法如下：

??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??

官網(wǎng)給出的讀寫分離+數(shù)據(jù)分片方案不能配置
spring.shardingsphere.sharding.default-data-source-name默認數(shù)據(jù)源，如果配置了，所有讀操作將全部指向主庫，無法達到讀寫分離的目的。

當我們困擾在讀從庫的查詢會被輪詢到分庫中，我們實際的場景從庫和分庫是分離的，分庫中根本就不存在從庫中的表。此問題困擾了我近兩天的時間，我閱讀源碼發(fā)現(xiàn)
spring.shardingsphere.sharding.default-data-source-name可以被賦值一個DataNodeGroup，不僅僅支持配置datasourceName，sharding源碼如下圖：

由此spring.shardingsphere.sharding.default-data-source-name配置為讀寫分離的groupname1，問題解決

從庫和分庫不在一起的場景下，讀寫分離+數(shù)據(jù)分配的配置如下：

#數(shù)據(jù)源名稱
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
#未配置分片規(guī)則的表將通過默認數(shù)據(jù)源定位，注意值必須配置為讀寫分離的分組名稱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


#由數(shù)據(jù)源名 + 表名組成，以小數(shù)點分隔。多個表以逗號分隔，支持inline表達式。缺省表示使用已知數(shù)據(jù)源與邏輯表名稱生成數(shù)據(jù)節(jié)點，用于廣播表（即每個庫中都需要一個同樣的表用于關聯(lián)查詢，多為字典表）或只分庫不分表且所有庫的表結構完全一致的情況
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 實現(xiàn)自己的讀寫分離負載均衡算法

Sharding提供了SPI形式的接口
org.apache.shardingsphere.spi.masterslave.MasterSlaveLoadBalanceAlgorithm實現(xiàn)讀寫分離多個從的具體負載均衡規(guī)則，代碼如下：

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 slaveDataSourceNames) {
        //自己的負載均衡規(guī)則
        return slaveDataSourceNames.get(0);

RoundRobinMasterSlaveLoadBalanceAlgorithm 實現(xiàn)為所有從輪詢負載

RandomMasterSlaveLoadBalanceAlgorithm 實現(xiàn)為所有從隨機負載均衡

4.4 關于某些場景下必須讀主庫的解決方案

某些場景比如分布式場景下寫入馬上讀取的場景，可以使用hint方式進行強制讀取主庫，Sharding源碼使用ThreadLocal實現(xiàn)強制路由標記。

下面封裝了一個注解可以直接使用，代碼如下：

@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 >讀寫分離自定義注解>用于實現(xiàn)讀寫分離時>需要強制讀主庫的場景（注解實現(xiàn)類）
 *
 * @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 關于官網(wǎng)對讀寫分離描述不夠明確的補充說明

版本4.1.1

經(jīng)實踐補充說明為：

同一線程且同一數(shù)據(jù)庫連接且一個事務中，如有寫入操作，以后的讀操作均從主庫讀取，只限存在寫入的表，沒有寫入的表，事務中的查詢會繼續(xù)路由至從庫中，用于保證數(shù)據(jù)一致性。

5 關于分庫的JOIN操作

方法1

使用default-data-source-name配置默認庫，即沒有配置數(shù)據(jù)分片策略的表都會使用默認庫。默認庫中表禁止與拆分表進行JOIN操作，此處需要做一些改造，目前系統(tǒng)有一些JOIN操作。（推薦使用此方法）

方法2

使用全局表，廣播表，讓128個庫中冗余基礎庫中的表，并實時改變。

方法3

分庫表中冗余需要JOIN表中的字段，可以解決JOIN問題，此方案單個表字段會增加。

6 分布式事務

6.1 XA事務管理器參數(shù)配置

XA是由X/Open組織提出的分布式事務的規(guī)范。 XA規(guī)范主要定義了(全局)事務管理器(TM)和(局 部)資源管理器(RM)之間的接口。主流的關系型 數(shù)據(jù)庫產(chǎn)品都是實現(xiàn)了XA接口的。

分段提交

XA需要兩階段提交: prepare 和 commit.

第一階段為 準備（prepare）階段。即所有的參與者準備執(zhí)行事務并鎖住需要的資源。參與者ready時，向transaction manager報告已準備就緒。

第二階段為提交階段（commit）。當transaction manager確認所有參與者都ready后，向所有參與者發(fā)送commit命令。

ShardingSphere默認的XA事務管理器為Atomikos，在項目的logs目錄中會生成xa_tx.log, 這是XA崩潰恢復時所需的日志，請勿刪除。

6.2 BASE柔性事務管理器（SEATA-AT配置）

Seata 是一款開源的分布式事務解決方案，提供簡單易用的分布式事務服務。隨著業(yè)務的快速發(fā)展，應用單體架構暴露出代碼可維護性差，容錯率低，測試難度大，敏捷交付能力差等諸多問題，微服務應運而生。微服務的誕生一方面解決了上述問題，但是另一方面卻引入新的問題，其中主要問題之一就是如何保證微服務間的業(yè)務數(shù)據(jù)一致性。Seata 注冊配置服務中心均使用 Nacos。Seata 0.2.1+ 開始支持 Nacos 注冊配置服務中心。

  • 按照seata-work-shop中的步驟，下載并啟動seata server。
  • 在每一個分片數(shù)據(jù)庫實例中執(zhí)創(chuàng)建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';
  • 在classpath中增加seata.conf
client {
    application.id = example    ## 應用唯一id
    transaction.service.group = my_test_tx_group   ## 所屬事務組
}

6.3 Sharding-Jdbc默認提供弱XA事務

官方說明：

完全支持非跨庫事務，例如：僅分表，或分庫但是路由的結果在單庫中。

完全支持因邏輯異常導致的跨庫事務。例如：同一事務中，跨兩個庫更新。更新完畢后，拋出空指針，則兩個庫的內容都能回滾。

不支持因網(wǎng)絡、硬件異常導致的跨庫事務。例如：同一事務中，跨兩個庫更新，更新完畢后、未提交之前，第一個庫死機，則只有第二個庫數(shù)據(jù)提交。

6.4 分布式事務場景

  • 保存場景

推薦使用第三種弱XA事務，盡量設計時避免跨庫事務，目前設計為事件和事件數(shù)據(jù)為同庫（分庫時，將一個線索號的事件和事件數(shù)據(jù)HASH進入同一個分庫），盡量避免跨庫事務。

事件和計費結果本身設計為異步，非同一事務，所以事件和對應的結果不涉及跨庫事務。

保存多個計費結果，每次保存都屬于一個事件，一個事件的計費結果都屬于一個收付款對象，天然同庫。

弱XA事務的性能最佳。

  • 更新場景

對一些根據(jù)ID IN的更新場景，根據(jù)收付款對象分組執(zhí)行，可以避免在所有分庫執(zhí)行更新。

  • 刪除場景

無，目前都是邏輯刪除，實際為更新。

7 總結

1.推薦使用Sharding-Sphere進行分庫，分表可以考慮使用MYSQL分區(qū)表，對于研發(fā)來講完全是透明的，可以規(guī)避JOIN\分布式事務等問題。（分區(qū)表需要為分區(qū)鍵+ID建立了一個聯(lián)合索引）MYSQL分區(qū)得到了大量的實踐印證，沒有BUG，包括我在新計費初期，一直堅持推動使用的分表方案，不會引起一些難以發(fā)現(xiàn)的問題，在同庫同磁盤下性能與分表相當。

2.對于同一時刻有大量并發(fā)讀操作和較少寫操作類型的數(shù)據(jù)來說，適合使用讀寫分離，增加多個讀庫，緩解主庫壓力，要注意的是必須讀主庫的場景使用SeekMaster注解來實現(xiàn)。

3.數(shù)據(jù)分庫選擇合適的分片鍵非常重要，要根據(jù)業(yè)務需求選擇好分庫鍵，盡力避免數(shù)據(jù)傾斜，數(shù)據(jù)不均勻是目前數(shù)據(jù)拆分的一個共同問題，不可能實現(xiàn)數(shù)據(jù)的完全均勻；當查詢條件沒有分庫鍵時會遍歷所有分庫，查詢盡量帶上分庫鍵。

4.在我們使用中間件時，不要只看官網(wǎng)解釋，要多做測試，用實際來驗證，有的時候官網(wǎng)解釋話術可能存在歧義或表達不夠全面的地方，分析源碼和實際測試可以清晰的獲得想要的結果。


當前名稱：國際財務系統(tǒng)基于ShardingSphere的數(shù)據(jù)分片和一主多從實踐
文章分享：http://m.5511xx.com/article/dheogsd.html