作者：京东物流张广治

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进行读写别离+数据分片时遇到了一个很大的问题，官网文档中的完成方式只合适分库和从库在一起时的场景如**（图四）**

而咱们的场景为**（图三）**所示，从库和分库时彻底分隔的，参考官网的完成办法如下：

shardingsphere.apache.org/document/4.…

官网给出的读写别离+数据分片计划不能装备
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.在咱们运用中间件时，不要只看官网解说，要多做测验，用实践来验证，有的时分官网解说话术可能存在歧义或表达不行全面的当地，剖析源码和实践测验能够清晰的取得想要的成果。

国际财务系统基于ShardingSphere的数据分片和一主多从实践

作者：京东物流张广治

1 布景

2 咱们的目标

3 数据分配规矩

4 读写别离一主多从

4.1ShardingSphere对读写别离的解说

4.2 读写别离+数据分片实战

4.3 完成自己的读写别离负载均衡算法

4.4 关于某些场景下有必要读主库的处理计划

4.5 关于官网对读写别离描绘不行清晰的补充阐明

5 关于分库的JOIN操作

6 分布式事务

6.1 XA事务管理器参数装备

6.2 BASE柔性事务管理器（SEATA-AT装备）

6.3 Sharding-Jdbc默许供给弱XA事务

6.4 分布式事务场景

7 总结

作者信息

国际财务系统基于ShardingSphere的数据分片和一主多从实践

作者：京东物流 张广治

1 布景

2 咱们的目标

3 数据分配规矩

4 读写别离一主多从

4.1ShardingSphere对读写别离的解说

4.2 读写别离+数据分片实战

4.3 完成自己的读写别离负载均衡算法

4.4 关于某些场景下有必要读主库的处理计划

4.5 关于官网对读写别离描绘不行清晰的补充阐明

5 关于分库的JOIN操作

6 分布式事务

6.1 XA事务管理器参数装备

6.2 BASE柔性事务管理器（SEATA-AT装备）

6.3 Sharding-Jdbc默许供给弱XA事务

6.4 分布式事务场景

7 总结

相关文章

代码diff服务改进方案

如何实现一个SQL解析器

由浅入深，揭秘企业级 OLAP 数据引擎 ByteHouse

Windows 通过 Git Bash 配置 Oh My Zsh

作者信息

作者：京东物流张广治