分库分表—1.简要概述-阿里云开发者社区

大纲

1.单库版本到分库分表的演进介绍

2.订单系统项目模版

3.完成一次查询全过程

4.磁盘IO为什么这么慢

5.MySQL的索引是如何形成的

6.SQL优化

7.千万级数据优化之加缓存—理论

8.千万级数据优化之加缓存—实战

9.千万级数据优化之读写分离-理论

10.千万级数据优化之读写分离-实战

11.千万级数据优化-水平拆分和垂直拆分

12.分库分表多数据源实战

13.分库分表后订单路由策略和全局ID

14.MyCat和ShardingSphere介绍

15.创建库和表的小工具

16.ShardingSphere数据分片核心原理

17.C端ShardingSphere分片策略实现

18.C端ShardingSphere读写分离实现

19.异构订单实现

20.单库亿级数据怎么迁移到多库多表上

1.单库版本到分库分表的演进介绍

(1)单库版本的电商系统架构

(2)SQL优化阶段

(3)缓存优化阶段

(4)读写分离优化阶段

(5)垂直分库优化阶段

(6)分库分表版本的订单系统架构

2.订单系统项目模版

(1)创建订单的时序图

(2)查询订单列表的时序图

3.完成一次查询全过程

(1)用户发起查询请求到MySQL的流程

(2)MySQL收到查询语句的处理流程

(3)InnoDB引擎对查询语句的处理流程

4.磁盘IO为什么这么慢

(1)一次磁盘IO花费的时间

(2)一次内存IO花费的时间

(3)磁盘IO分为随机读写和顺序读写

(1)一次磁盘IO花费的时间

读写磁头在磁盘扇区上读取或者写入数据花费的时间，也就是一次完整的磁盘IO花费的时间，包括如下三个方面：

一.寻道时间

指的就是读写磁头移动到正确的半径上所需要的时间。寻道时间越短，磁盘IO操作越快。一般磁盘的寻道时间是3-15ms，主流的磁盘寻道时间是5ms。

二.旋转延迟时间

找到正确的磁道后，读写磁头移动到正确的位置上所消耗的时间。一般取磁盘旋转周期的一半作为旋转延迟的近似值：7200转/分 -> 120转/秒 -> 每转1/120秒 -> 每转的一半是1/240秒即4ms。

三.数据传输时间

指的是将数据从磁盘盘片读取或者写入的时间。一般是1ms以内，可以忽略不计。所以主流磁盘的一次磁盘IO的时间为：5ms + 4ms = 9ms。

(2)一次内存IO花费的时间

内存读取一次数据，一般是100ns以内，而1ms = 10^6ns = 100万ns。所以一次磁盘IO花费的时间是一次内存IO花费时间的约9万倍，几万倍。

(3)磁盘IO分为随机读写和顺序读写

一.顺序读写

就是读写磁头按照顺序读写磁盘盘片中的数据，速度还是很快的。MySQL里的binlog和redo日志就是顺序读写的。

二.随机读写

就是读写磁头会随机切换到不同的磁盘盘片的位置，速度比较缓慢耗时。

5.MySQL的索引是如何形成的

(1)数据页的结构

(2)数据区中存放的多个数据行组成单向链表

(3)多个数据页则组成双向链表

(4)索引页会存放数据页页号 + 其最小主键ID

(5)多个索引页的展示图

(1)数据页的结构

(2)数据区中存放的多个数据行组成单向链表

(3)多个数据页则组成双向链表

(4)索引页会存放数据页页号 + 其最小主键ID

(5)多个索引页的展示图

数据页和索引页组成的B+树中，叶子节点是数据页，非叶子节点是索引页。B+树的时间复杂度是log(n)。

6.SQL优化

(1)SQL优化流程

(2)SQL优化中的join优化原理算法

(1)SQL优化流程

判断join语句 -> 判断where条件 -> 判断聚合函数 -> 判断排序

(2)SQL优化中的join优化原理算法

SQL优化中不管是对where语句、聚合函数、还是排序操作的优化，优化起来相对而言会简单点，为对应的字段创建合适的索引即可。但是join语句这块的优化涉及到一些比较重要的如下原理了。

简单来说，在MySQL中使用join语句关联2张表的话，比如执行这条SQL：

select t1.order_no, t2.product_id 
from order_info t1 
left join order_item_detail t2 
on t1.order_no = t2.order_no

这个时候，join关联查询的过程是什么样子的呢？其实，这个就取决于当前join语句用到的算法了，join语句一共有3种算法。

第一种：最基础的是Simple Nested Loop算法

简单嵌套循环算法，相当于双重for循环。

第二种：Block Nested Loop算法

MySQL提供了一个Join Buffer，但是Join Buffer大小为256K，内存有限。当然我们也可以通过join buffer size参数调节Join Buffer的大小。

第三种：Index Nested Loop算法

原来的匹配次数为：驱动表行数 * 被驱动表行数，而现在变成了：驱动表行数 * 被驱动表索引的高度。这样就极大地减少了被驱动表的匹配次数，极大地提升了join的性能。

总结：如果join关联查询能使用到索引，MySQL就会使用Index Nested Loop算法，查询效率会比较高。如果无法使用Index Nested Loop算法，MYSQL默认会使用Block Nested Loop算法，查询效率会很慢。

7.千万级数据优化之加缓存—理论

(1)高峰期导致数据库压力很大

(2)加缓存进行流量削峰

(3)如何提高缓存命中率

(1)高峰期导致数据库压力很大

通过对SQL优化特别是添加索引，可以提升查询的速度。此时已将SQL的一次查询稳定在300ms以下，但有一天DBA告知有一条SQL偶尔会超过2s。

为什么SQL查询时间会偶尔激增超过2s呢？通过排查发现，这条SQL在平时是没有问题的，一般稳定在300ms以下。经过分析和发现，在高峰期这条SQL才偶尔会超过2s。原因是在高峰期的时候，这台服务器的资源占用非常高。

所以定位到问题的原因是：高峰期时，大量请求会跑到MySQL数据库，从而导致这台服务器的CPU和内存占用率迅速飙升，最终导致数据库查询非常慢。

(2)加缓存进行流量削峰

解决方案：通过加缓存解决问题。

缓存的目的：为了流量削峰，减轻MySQL的负载，让MySQL稳定的去提供读写。

虽然说缓存非常好用，但是需要注意缓存命中率。缓存命中率 = 命中缓存的结果数 / 请求的缓存数。缓存命中率是衡量缓存有效性的重要指标。也就是说，命中率越高缓存的使用率越高。

(3)如何提高缓存命中率

第一：选择合适的业务场景

缓存适合读多写少的场景，最好是高频访问的场景，这里以已经完成订单为例。

第二：合理设置缓存容量

缓存容量如果很小则会触发Redis内存淘汰机制，导致key被删除，从而没能起到缓存效果。

一般都是二八原则，总数据量的20%会放在Redis里面，通常会根据业务场景取总数据量的15%到30%放到Redis中。

第三：控制缓存的粒度

单个key的数据单位越小，这个缓存就越不容容易更改，粒度越小缓存率越高。

第四：灵活设置缓存过期时间

如果缓存过期的时间设置不好，则可能会导致key同时失效。从而导致所有的请求都同时到数据库当中，这就是缓存击穿。

第五：避免缓存的穿透

查询一条数据，先从Redis缓存里查。如果没有，再从数据库中查，数据库中也没有，就说明缓存穿透。如果大量的请求过来，Redis中没有，数据库中也没有，就会把数据打穿。缓存穿透会造成缓存雪崩，导致最后服务崩溃。

解决办法：可以在缓存中给这个查询的请求设置一个空对象，让这个请求拿着空对象返回，然后设置到Redis缓存里。

第六：做好缓存预热

我们可以提前将数据库的数据(热点数据)放入到Redis缓存当中，这样第一次查询时就可以直接走缓存了。

下面是各个硬件的执行时间和容量：

CPU：20-50ns，1-32M级别

内存：100ns，32-96GB级别

磁盘：3-5ms，TB或PB级别

8.千万级数据优化之加缓存—实战

(1)业务场景是对历史订单进行查询

(2)Redis缓存的代码

(1)业务场景是对历史订单进行查询

由于历史订单的状态不会发生变化，符合读多写少的场景。所以可把用户的查询结果放入Redis缓存，并设置过期时间为1小时。只要缓存失效前再次查询，就会查Redis进行流量削峰来减轻数据库压力。

(2)Redis缓存的代码

缓存key的生成规则是：用户的ID+当前页+页数。

@RestController
@RequestMapping(value = "/user/order")
public class UserOrderController {
    @Autowired
    private UserOrderInfoService userOrderInfoService;
    ...
    // 查询订单列表
    @PostMapping("/queryOrderInfoList")
    public PageResponse queryOrderInfoList(@RequestBody OrderInfoQuery orderInfoQuery) {
        //开始计时
        long bTime = System.currentTimeMillis();
        try {
            Page<OrderInfoVO> orderInfoPage = userOrderInfoService.queryOrderInfoList(orderInfoQuery);
            //关闭分段计时
            long eTime = System.currentTimeMillis();
            //输出
            log.info("查询用户订单耗时：" + (eTime - bTime));
            return PageResponse.success(orderInfoPage);
        } catch (Exception e) {
            log.info(e.getMessage());
            return PageResponse.error(e.getMessage());
        }
    }
    ...
}
//用户订单服务实现
@Service
public class UserOrderInfoServiceImpl implements UserOrderInfoService {
    private final static Long FINISH = 50L;
    @Autowired
    private OrderInfoRepository orderInfoRepository;
    @Autowired
    private RedisUtils redisUtils;
    ...
    @Override
    public Page<OrderInfoVO> queryOrderInfoList(OrderInfoQuery orderInfoQuery) {
        OrderValidation.checkVerifyOrderQuery(orderInfoQuery);
        Page<OrderInfoVO> page = new Page<OrderInfoVO>();
        page.setCurrent(orderInfoQuery.getCurrent());
        page.setSize(orderInfoQuery.getSize());
        //查询已完成的订单
        if (FINISH.equals(orderInfoQuery.getOrderStatus())) {
            //组装redisKey
            String redisKey = orderInfoQuery.getUserId() + orderInfoQuery.getCurrent().toString() + orderInfoQuery.getSize().toString();
            //获取redis缓存
            Object redisObject = redisUtils.get(redisKey);
            //redis为空则从数据库中查询
            if (Objects.isNull(redisObject)) {
                Page<OrderInfoVO> userOrderInfoVOPage = orderInfoRepository.queryOrderInfoList(page, orderInfoQuery);
                //设置redis缓存，过期时间为一小时
                redisUtils.set(redisKey, userOrderInfoVOPage, 3600L, TimeUnit.SECONDS);
                return userOrderInfoVOPage;
            }
            log.info("从redis中获取数据, key: {}", redisKey);
            return (Page<OrderInfoVO>) redisObject;
        }
        return orderInfoRepository.queryOrderInfoList(page, orderInfoQuery);
    }
    ...
}

9.千万级数据优化之读写分离-理论

(1)读写分离的业务背景

(2)主从复制的原理是什么

(3)主从复制的几种模式

(1)读写分离的业务背景

营销系统那边做了一些活动，导致订单请求量突增，大量下单的用户可能会不断刷新订单来查询订单是否配送等信息。

此时大量的请求会打到MySQL上，而单库又抗不了这么多读请求。这就会导致数据库负载很高，从而严重降低MySQL的查询效率。现在我们缓存也加过了，但是数据库负载还是很高，此时该怎么办？

其实很简单，既然单个库扛不住，那就搞2个库一起来抗。因为这对于订单系统来说是典型的读多写少场景，所以在这个场景下可以搞个一主两从的架构来进行优化，就像如下这样：

也就是写数据走主库，而读数据走从库，并且多个从库可以一起来抗大量的读请求。关键的一点是，从库会通过主从复制，从主库中不断的同步数据，以此来保证从库的数据和主库一致。所以想要实现读写分离，那么就先要了解主从复制的具体原理。

(2)主从复制的原理是什么

我们以MySQL一主两从架构为例，也就是一个Master节点下有两个Slave节点。在这套架构下，写请求统一交给Master节点处理，而读请求交给Slave节点处理。

为了保证Slave节点和Master节点的数据一致性：Master节点在写入数据后，同时会把数据复制一份到自己的各个Slave节点上。

在复制过程中一共会使用到三个线程：一个是Binlog Dump线程，位于Master节点上。另外两个线程分别是IO线程和SQL线程，它们都分别位于Slave节点上。如下图示：

主从复制的核心流程：

步骤一：首先，当Master节点接收到一个写请求时，这个写请求可能是增删改操作。此时会把写请求的操作都记录到BinLog日志中。

步骤二：然后，Master节点会把数据复制给Slave节点，这个过程首先要每个Slave节点连接到Master节点上。当Slave节点连接到Master节点上时，Master节点会为每一个Slave节点分别创建一个BinLog Dump线程。每个BinLog Dump线程用于向各个Slave节点发送BinLog日志。

步骤三：BinLog Dump线程会读取Master节点上的BinLog日志，并将BinLog日志发送给Slave节点上的IO线程。

步骤四：Slave节点上的IO线程接收到BinLog日志后，会将BinLog日志先写入到本地的RelayLog中。Slave节点的RelayLog中就保存了Master的BinLog Dump线程发送过来的BinLog日志。

步骤五：最后，Slave节点上的SQL线程就会来读取RelayLog中的BinLog日志，将其解析成具体的增删改操作。然后把这些在Master节点上进行过的操作，重新在Slave节点上也重做一遍，达到数据还原的效果。这样就可保证Master节点和Slave节点的数据一致性。

(3)主从复制的几种模式

MySQL的主从复制，分为全同步复制、异步复制、半同步复制和增强半同步复制这四种。

模式一：全同步复制

全同步复制就是当主库执行完一个事务后，所有从库也必须执行完该事务才可以返回结果给客户端。因此虽然全同步复制数据一致性得到保证，但主库完成一个事务需等待所有从库也完成，性能较低。

模式二：异步复制

异步复制就是当主库提交事务后，会通知BinLog Dump线程发送BinLog日志给从库。一旦BinLog Dump线程将BinLog日志发送给从库后，无需等从库也同步完事务，主库就会将处理结果返回给客户端。

因为主库只管自己执行完事务，就可以将处理结果返回给客户端，而不用关心从库是否执行完事务。这就可能导致短暂的主从数据不一致，比如刚在主库插入的新数据，如果马上在从库查询，就可能查询不到。

而且当主库提交事务后，如果宕机挂掉了，此时可能BinLog还没来得及同步给从库。这时如果为了恢复故障切换主从节点，就会出现数据丢失的问题。所以异步复制虽然性能高，但数据一致性上是较弱的。

不过MySQL主从复制，默认采用的就是异步复制这种复制策略。

模式三：半同步复制

半同步复制就是在同步和异步中做了折中选择，半同步主从复制的过程如下图示：

当主库提交事务后，至少还需要一个从库返回接收到BinLog日志，并成功写入到RelayLog的消息，这时主库才会将处理结果返回给客户端。相比前2种复制方式，半同步复制较好地兼顾了数据一致性以及性能损耗的问题。

但半同步复制也存在以下几个问题：

问题一：半同步复制的性能相比异步复制有所下降。因为异步复制是不需要等待任何从库是否接收到数据的响应，而半同步复制则需要等待至少一个从库确认接收到binlog日志的响应，性能上是损耗更大。

问题二：如果超过了配置的主库等待从库响应的最大时长，半同步复制就会变成异步复制，此时异步复制的问题同样会出现。

问题三：在MySQL 5.7.2之前的版本中，半同步复制存在着幻读问题。当主库成功提交事务并处于等待从库确认过程，这时从库都还没来得及返回处理结果给客户端，但因为主库存储引擎内部已经提交事务了，所以其他客户端是可以到从主库中读到数据的。但是如果下一秒主库突然挂了，那么下一次请求过来时，就只能把请求切换到从库中。而因为从库还没从主库同步完数据，所以从库就读不到这条数据了。和上一秒读取数据的结果对比，就造成了幻读的现象。注意这不是数据丢失，因为后续从库会同步完数据的。

模式四：增强半同步复制

增强半同步复制是MySQL 5.7.2后的版本对半同步复制做的一个改进。原理上几乎是一样的，主要是解决幻读的问题。主库配置了参数rpl_semi_sync_master_wait_point = AFTER_SYNC后，主库在提交事务前必须先收到从库数据同步完成的确认信息，才能提交事务，以此来解决幻读问题。增强半同步主从复制过程如下：

10.千万级数据优化之读写分离-实战

(1)读写分离配置核心组件流程图

(2)读写分离的实现步骤

(1)读写分离配置核心组件流程图

(2)读写分离的实现步骤

步骤一：配置文件中配置主从库连接信息

application.yaml配置文件

spring:
  datasource:
    masters:
    - url: jdbc:mysql://192.168.10.8:3307/order_db?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT
      username: root
      password: Sharding@Master#1990
      driver-class-name: com.mysql.cj.jdbc.Driver
    slaves:
    - url: jdbc:mysql://192.168.10.8:3308/order_db?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT
      username: root
      password: Sharding@Slave#1990
      driver-class-name: com.mysql.cj.jdbc.Driver

步骤二：注入数据源

DataSourceConfig类

//多数据源配置
@Configuration
@ConfigurationProperties(prefix = "spring.datasource")
public class DataSourceConfig {
    //主库数据源信息
    private Map<String, String> masters;
    //从库数据源信息
    private List<Map<String, String>> slaves;
    @Bean
    public DataSource masterDataSource() throws Exception {
        if (CollectionUtils.isEmpty(masters)) {
            throw new Exception("主库数据源不能为空");
        }
        return DruidDataSourceFactory.createDataSource(masters);
    }
    @Bean
    public List<DataSource> slaveDataSources() throws Exception {
        if (CollectionUtils.isEmpty(slaves)) {
            throw new Exception("从库数据源不能为空");
        }
        final List<DataSource> dataSources = new ArrayList<>();
        for (Map map : slaves) {
            dataSources.add(DruidDataSourceFactory.createDataSource(map));
        }
        return dataSources;
    }
    @Bean
    @Primary
    @DependsOn({"masterDataSource", "slaveDataSources"})
    public DataSourceRouter routingDataSource() throws Exception {
        final Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put(DataSourceContextHolder.MASTER, masterDataSource());
        for (int i = 0; i < slaveDataSources().size(); i++) {
            targetDataSources.put(DataSourceContextHolder.SLAVE + i, slaveDataSources().get(i));
        }
        final DataSourceRouter routingDataSource = new DataSourceRouter();
        routingDataSource.setTargetDataSources(targetDataSources);
        routingDataSource.setDefaultTargetDataSource(masterDataSource());
        return routingDataSource;
    }
    //设置事务，事务需要知道当前使用的是哪个数据源才能进行事务处理
    @Bean
    public DataSourceTransactionManager dataSourceTransactionManager() throws Exception {
        return new DataSourceTransactionManager(routingDataSource());
    }
    public Map<String, String> getMasters() {
        return masters;
    }
    public void setMasters(Map<String, String> masters) {
        this.masters = masters;
    }
    public List<Map<String, String>> getSlaves() {
        return slaves;
    }
    public void setSlaves(List<Map<String, String>> slaves) {
        this.slaves = slaves;
    }
}

步骤三：数据源切换上下文，其中使用了ThreadLocal保存当前线程的数据源

DataSourceContextHolder类

//数据源上下文
public class DataSourceContextHolder {
    public static final String MASTER = "MASTER";
    public static final String SLAVE = "SLAVE";
    private static final ThreadLocal<String> CONTEXT_HOLDER = new ThreadLocal<>();
    //默认写模式
    public static String getDataSourceType() {
        return CONTEXT_HOLDER.get() == null ? MASTER : CONTEXT_HOLDER.get();
    }
    public static void setDataSourceType(String dataSourceType) {
        if (dataSourceType == null) {
            log.error("dataSource为空");
            throw new NullPointerException();
        }
        log.info("设置dataSource：{}", dataSourceType);
        CONTEXT_HOLDER.set(dataSourceType);
    }
    public static void removeDataSourceType() {
        CONTEXT_HOLDER.remove();
    }
}

步骤四：继承AbstractRoutingDataSource类重写determineCurrentLookupKey方法实现数据源动态切换

DataSourceRouter类继承了SpringBoot的AbstractRoutingDataSource类，并且重写了determineCurrentLookupKey方法来实现数据源动态切换。

//动态主从数据源切换
public class DataSourceRouter extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        log.info("当前数据源为" + DataSourceContextHolder.getDataSourceType());
        //返回选择的数据源
        return DataSourceContextHolder.getDataSourceType();
    }
}

步骤五：创建读库的自定义注解

//自定义读库注解
//被这个注解的方法使用读库
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
@Inherited
public @interface ReadOnly {
}

步骤六：切面类DynamicDataSourceAsepct

//数据源切面
@Aspect
@Component
public class DynamicDataSourceAspect implements Ordered {
    //在Service层方法获取DataSource对象之前，在切面中指定当前线程数据源Slave
    @Before(value = "execution(* *(..)) && @annotation(readOnly)")
    public void before(JoinPoint point, ReadOnly readOnly) {
        log.info(point.getSignature().getName() + "走从库");
        DataSourceContextHolder.setDataSourceType(DataSourceContextHolder.SLAVE);
    }
    @After(value = "execution(* *(..)) && @annotation(readOnly)")
    public void restoreDataSource(JoinPoint point, ReadOnly readOnly) {
        log.info(point.getSignature().getName() + "清除数据源");
        //方法执行完后清除数据源
        DataSourceContextHolder.removeDataSourceType();
    }
    @Override
    public int getOrder() {
        return 0;
    }
}

步骤七：在需要走读库的业务方法上添加@ReadOnly注解

这样执行这些业务方法时就会被切面拦截修改数据源，从而走读库进行查询。

//用户订单服务实现
@Service
public class UserOrderInfoServiceImpl implements UserOrderInfoService {
    ...
    //获取订单详情
    @ReadOnly
    @Override
    public OrderDetailVO getOrderDetail(String orderNo) {
        return orderInfoRepository.getOrderDetail(orderNo);
    }
    ...
}

11.千万级数据优化-水平拆分和垂直拆分

(1)什么时候考虑水平拆分和垂直拆分

(2)什么是垂直拆分

(3)什么是水平拆分

(1)什么时候考虑水平拆分和垂直拆分

当数据库的数据量越来越大时：首先可以从SQL入手进行优化，比如通过加入索引。然后可以使用缓存来进行优化，适合读多写少的场景。接着可以通过主从复制和读写分离来实现优化。此时增删改已全部走主库，查询都走从库，已经大大提升了读数据的能力。但是没有办法提升主库写数据能力，于是可以考虑对数据进行水平拆分和垂直拆分了。

(2)什么是垂直拆分

原来很多模块共用一个数据库资源，经过垂直分库后，商品模块、订单模块、用户模块等使用上自己单独的数据资源，于是各模块的资源竞争就不存在了。

垂直拆分的好处：

一.减轻了数据库的压力

二.每个数据库分摊数据，提高了查询的效率

三.每个数据库访问的CPU、内存、网络压力变小

四.业务更加清晰

五.解耦

六.系统扩展也变得容易

垂直拆分带来的不足：

一.系统的复杂性增加了

二.增加了多个数据库数据表联查的复杂性

三.事务处理变得麻烦

四.垂直拆分也解决不了单表数据量很大的问题

(3)什么是水平拆分

单表数据量很大可能会引起接口查询超时的问题。

履约系统会通过Dubbo发起RPC请求调用订单系统。假如设置的超时间为1s，此时订单模块的查询时间就已经快1s了，很容易超时。而一旦延长超时时间成5s，那么履约系统的的线程池就很容易被打满，导致资源迅速被耗尽，甚至会导致履约系统的服务雪崩。所以垂直拆分解决不了单表数据量很大的问题，需要水平拆分。

水平拆分时表的结构不会发生改变，水平拆分分为：水平拆表、水平分库、水平分库分表。

一.水平拆表如下

二.水平拆库如下

三.水平分库分表

水平拆分带来的不足：

一.水平拆分过程比较复杂

二.事务处理变得复杂

三.多库多表联查难度加大

四.水平拆分之后单表的数据会分散到不同的数据源中(多数据源管理问题)

12.分库分表多数据源实战

(1)首先配置好三个数据源

(2)然后创建一个数据库配置DataSourceConfig读入三个数据源的具体配置

(3)创建数据源上下文DataSourceContextHolder

(4)DataSourceRouter继承SpringBoot的AbstractRoutingDataSource实现动态切换数据源

(5)创建DataSources将数据源配置注入到DataSourceConfig对象中并交给SpringBoot管理

(6)在业务中设置当前线程的数据源类型

(1)首先配置好三个数据源

datasources.properties

spring.datasource01.url=jdbc:mysql://192.168.10.8:3307/order_db?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT
spring.datasource01.username=root
spring.datasource01.password=Sharding@Master#1202
spring.datasource01.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource02.url=jdbc:mysql://192.168.10.8:3307/order_db?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT
spring.datasource02.username=root
spring.datasource02.password=Sharding@Master#1202
spring.datasource02.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource03.url=jdbc:mysql://127.0.0.1/demo?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT
spring.datasource03.username=root
spring.datasource03.password=123456
spring.datasource03.driver-class-name=com.mysql.cj.jdbc.Driver

(2)然后创建一个数据库配置DataSourceConfig读入三个数据源的具体配置

//数据库配置
@Data
public class DataSourceConfig {
    //driverClassName驱动名称
    private String driverClassName;
    //url
    private String url;
    //用户名
    private String username;
    //密码
    private String password;
}

(3)创建数据源上下文DataSourceContextHolder

写死各个数据源，并且为每个线程创建一个副本，当并发访问时，每个线程可以找到它对应的数据源。

//数据源上下文
public class DataSourceContextHolder {
    public static final String DATA_SOURCE_01 = "datasource01";
    public static final String DATA_SOURCE_02 = "datasource02";
    public static final String DATA_SOURCE_03 = "datasource03";
    private static final ThreadLocal<String> CONTEXT_HOLDER = new ThreadLocal<>();
    public static void setDataSourceType(String dataSourceType) {
        if (dataSourceType == null) {
            log.error("dataSource为空");
            throw new NullPointerException();
        }
        log.info("设置dataSource：{}", dataSourceType);
        CONTEXT_HOLDER.set(dataSourceType);
    }
    public static String getDataSourceType() {
        return CONTEXT_HOLDER.get();
    }
    //根据取模结果，设置当前线程的数据源类型
    public static void setDataSourceType(Long userId) {
        Long result = userId % DataSources.getDataSourceSize();
        if (result == 0) {
            DataSourceContextHolder.setDataSourceType(DataSourceContextHolder.DATA_SOURCE_01);
        } else if (result == 1) {
            DataSourceContextHolder.setDataSourceType(DataSourceContextHolder.DATA_SOURCE_02);
        } else {
            DataSourceContextHolder.setDataSourceType(DataSourceContextHolder.DATA_SOURCE_03);
        }
    }
    public static void removeDataSourceType() {
        CONTEXT_HOLDER.remove();
    }
}

(4)DataSourceRouter继承SpringBoot的AbstractRoutingDataSource实现动态切换数据源

当创建了数据源上下文DataSourceContextHolder，每个线程是怎么找到它对应的数据源呢？

首先肯定需要在请求开始的时候通过DataSourceContextHolder的setDataSourceType()方法设置线程的数据源。由于DataSourceRouter继承SpringBoot的AbstractRoutingDataSource重写了determineCurrentLookupKey()方法，而在AbstractRoutingDataSource中SpringBoot已经实现了动态切换数据源的路由，所以每个线程便能借助SpringBoot去找到它对应的数据源了。

(5)创建DataSources将数据源配置注入到DataSourceConfig对象中并交给SpringBoot管理

//多数据源配置
@Configuration
@PropertySource("classpath:datasources.properties")
@ConfigurationProperties(prefix = "spring")
public class DataSources {
    //数据源集合
    private static List<DataSource> dataSources = new ArrayList<DataSource>();
    //数据源01信息
    private DataSourceConfig datasource01;
    //数据源02信息
    private DataSourceConfig datasource02;
    //数据源03信息
    private DataSourceConfig datasource03;
    //获取数据源数量
    public static int getDataSourceSize() {
        return dataSources.size();
    }
    @Bean
    public List<DataSource> ds() throws Exception {
        dataSources.add(buildDruidDataSource(datasource01));
        dataSources.add(buildDruidDataSource(datasource02));
        dataSources.add(buildDruidDataSource(datasource03));
        return dataSources;
    }
    //构建Druid数据源
    public DruidDataSource buildDruidDataSource(DataSourceConfig dataSourceConfig) {
        return DataSourceBuilder.create()
            .type(DruidDataSource.class)
            .driverClassName(dataSourceConfig.getDriverClassName())
            .url(dataSourceConfig.getUrl())
            .username(dataSourceConfig.getUsername())
            .password(dataSourceConfig.getPassword())
            .build();
    }
    @Bean
    @Primary
    public DataSourceRouter routingDataSource() throws Exception {
        Map<Object, Object> targetDataSources = new HashMap<>();
        List<DataSource> dataSources = ds();
        targetDataSources.put(DataSourceContextHolder.DATA_SOURCE_01, dataSources.get(0));
        targetDataSources.put(DataSourceContextHolder.DATA_SOURCE_02, dataSources.get(1));
        targetDataSources.put(DataSourceContextHolder.DATA_SOURCE_03, dataSources.get(2));
        DataSourceRouter routingDataSource = new DataSourceRouter();
        routingDataSource.setTargetDataSources(targetDataSources);
        routingDataSource.setDefaultTargetDataSource(dataSources.get(0));
        return routingDataSource;
    }
    //设置事务，事务需要知道当前使用的是哪个数据源才能进行事务处理
    @Bean
    public DataSourceTransactionManager dataSourceTransactionManager() throws Exception {
        return new DataSourceTransactionManager(routingDataSource());
    }
    public DataSourceConfig getDatasource01() {
        return datasource01;
    }
    
    public void setDatasource01(DataSourceConfig datasource01) {
        this.datasource01 = datasource01;
    }
    
    public DataSourceConfig getDatasource02() {
        return datasource02;
    }
    
    public void setDatasource02(DataSourceConfig datasource02) {
        this.datasource02 = datasource02;
    }
    
    public DataSourceConfig getDatasource03() {
        return datasource03;
    }
    
    public void setDatasource03(DataSourceConfig datasource03) {
        this.datasource03 = datasource03;
    }
}

(6)在业务中设置当前线程的数据源类型

@Repository
public class OrderInfoRepository {
    ...
    //查询用户订单列表
    public Page<OrderInfoVO> queryOrderInfoList(OrderInfoBaseQuery orderInfoBaseQuery) {
        //1.组装mybatis查询插件
        Page page = new Page();
        page.setCurrent(orderInfoBaseQuery.getPageNo());
        page.setSize(orderInfoBaseQuery.getPageSize());
        //2.设置当前线程的数据源类型
        DataSourceContextHolder.setDataSourceType(orderInfoBaseQuery.getUserId());
        //3.查询该用户订单信息
        Page<OrderInfoVO> orderInfoVOPage = orderInfoMapper.queryOrderInfoList(page, orderInfoBaseQuery);
        return orderInfoVOPage;
    }
    ...
}

13.分库分表后订单路由策略和全局ID

(1)为什么需要路由策略

(2)路由策略的设计

(3)全局ID的作用

(4)全局唯一ID的算法之雪花算法

(1)为什么需要路由策略

一.分库分表后必须要支持的场景

场景一：用户下单后需要查看订单信息了解订单状态

场景二：商家需要获取订单信息进行分析

二.分库分表后不同数据会分散在不同的库表

一个用户下单后，订单可能会落在不同的表中，他查询自己的订单列表时可能需要查多张表。同样，商家查询他的订单列表时也可能需要查多张表。

所以希望根据一定规则，让同一个用户下的单在同一张表，同一个商家的单在同一张表，这个规则就是路由策略。

(2)路由策略的设计

一.用户的路由策略之使用用户ID作为路由Key

单库多表的路由策略：用户ID的Hash值 % 3

用户下单时，把用户ID作为路由Key：
首先对用户ID取Hash值，然后对表的数量进行取模。

多库多表的路由策略：需要先找到库再找到表

找库：根据用户ID的Hash值对数据库的数量进行取模找到对应的数据库；
找表：根据用户ID的Hash值除以数据库的数量接着再对表的数量进行取模找到对应的表；

可以用2库3表来简单举1-10的ID例子分析理解

找库：用户ID的Hash值 % 2；
找表：用户ID的Hash值 / 2 % 3；

设计路由策略的要点：根据具体的业务场景、与用户信息关联度比较大的路由Key进行Hash值取模。

二.商家的路由策略之使用商家ID作为路由Key并单独为商家B端设计一张订单表

很明显不能使用用户ID作为商家的路由Key。我们会单独为商家B端设计了一张订单表，也就是C端和B端的订单表是相互独立的。

用户的角度查询订单，是以用户ID作为路由Key。商家的角度查询订单，是以商家ID作为路由Key。B端订单表的路由策略和C端订单表的路由策略是一致的，仅仅是路由Key不同。

那么如何为B端的订单表写入数据呢？当C端用户下单时，会把订单号发送到MQ。然后B端会消费这个MQ消息，根据订单号获取订单信息，然后写入到B端的订单表中。

(3)全局ID的作用

全局ID是为了解决订单主键重复的问题。可以引入一个全局唯一ID的服务，用来生成全局唯一ID。该服务每次生成的ID都不一样，可以保证主键的唯一性。

(4)全局唯一ID的算法之雪花算法

雪花算法生成的ID一共64个bit位 = 8字节。

第一部分：0表示正数。

第二部分：41位的时间戳，2^41 - 1 = 69年。

第三部分：10位的全局机器ID，其中5位的数据中心 + 5位机器ID。2 ^10 = 1024，表示在同一个时间戳下，最多可允许1024台机器得到全局唯一ID。

第四部分：12位的序列号 2^12 = 4096。

雪花算法的含义：

就是同一个时间戳下，可为1024台机器获取全局唯一ID，可为每台机器并发分配4096个ID。

雪花算法的ID生成类：

public class IdGenerater {
    //数据中心id：外部传入
    private long datacenterId;
    //机器id：外部传入
    private long workerId;
    //12位的序列号
    private long sequence;
    //数据中心id的bit位数
    private long datacenterIdBits = 5L;
    //工作id的bit位数
    private long workerIdBits = 5L;
    //序列号bit位数
    private long sequenceBits = 12L;
    //工作id向左移动位数：12位
    private long workerIdShift = sequenceBits;
    //数据id向左移动位数：12 + 5 = 17位
    private long datacenterIdShift = sequenceBits + workerIdBits;
    //时间戳需要左移位数 12 + 5 + 5 = 22位
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    //序列号最大值
    private long sequenceMask = -1L ^ (-1L << sequenceBits);
    //初始时间戳
    private long initialTimestamp = 1288834974657L;
    //上次时间戳，初始值为负数是不想浪费 lastTimestamp + 1 = 0 这个序列号
    private long lastTimestamp = -1L;
    
    public IdGenerater(long workerId, long datacenterId, long sequence) {
        this.workerId = workerId;
        this.datacenterId = datacenterId;
        this.sequence = sequence;
    }
    
    //通过雪花算法生成一个ID 
    public synchronized long nextId() throws Exception {
        long timestamp = System.currentTimeMillis();
        //获取当前时间戳：当前时间戳不能小于上次的获取的时间戳
        if (timestamp < lastTimestamp) {
            throw new RuntimeException("当前时间戳小于上次的时间戳，可能时钟回拨了！");
        }
        //当前时间戳，如果等于上次时间戳（同一毫秒内），则序列号加一
        //否则序列号赋值为0，从0开始
        if (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //序列号超过12个bit位、也就是已经生成4096个ID了
            //那这一毫秒内就不能再生成新的ID了，切换到下一毫秒内
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            //第一个ID的序列号，从0开始
            sequence = 0;
        }
        //将当前时间戳设置为最近的一次时间戳
        lastTimestamp = timestamp;
        
        //返回结果：
        //(timestamp - initialTimestamp) << timestampLeftShift) 表示将时间戳减去初始时间戳，再左移相应位数 
        //(datacenterId << datacenterIdShift) 表示将数据id左移相应位数
        //(workerId << workerIdShift) 表示将工作id左移相应位数
        return ((timestamp - initialTimestamp) << timestampLeftShift) | 
            (datacenterId << datacenterIdShift) | 
            (workerId << workerIdShift) | sequence;
    }
    
    //获取时间戳，并与上次时间戳比较
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = System.currentTimeMillis();
        while (timestamp <= lastTimestamp) {
            timestamp = System.currentTimeMillis();
        }
        return timestamp;
    } 
}

雪花算法的测试类：

//测试雪花算法生成ID
public class SnowFlakeTest {
    public static void main(String[] args) throws Exception {
        IdGenerater worker = new IdGenerater(1, 1, 1);
        for (int i = 0; i < 5; i++) {
            long id = worker.nextId();
            System.out.println("id为：" + id);
            System.out.println("二进制id为：" + Long.toBinaryString(id));
        }
    }
}

需要注意雪花算法的时钟回拨问题：也就是存在的人为调整系统时间，导致生成同样的ID。

雪花算法的时钟回拨问题的解决方案：可以把上一次系统获取到的时间戳缓存起来，每次获取时间戳和上次的进行比较。如果小于上一次，就证明时钟回拨，这时候就可以取上次时间戳 + 1即可。

14.MyCat和ShardingSphere介绍

(1)MyCat简介

(2)ShardingSphere简介

(1)MyCat简介

如果没有MyCat，系统需要自己管理数据库的配置。

如果有MyCat，数据库的配置会由MyCat管理。同时MyCat可以帮我们完成：读写分离、数据分片路由、多数据源管理等功能。

具体的流程如下：

MyCat适用于中小型公司、创业公司，MyCat是需要单独部署一个服务。如果数据库特别多，则MyCat的压力会变得很大，从而导致性能降低。

(2)ShardingSphere简介

和MyCat不一样的是，ShardingSphere只是一个jar包，更加轻量级。只需要在项目中引入即可，无需独立部署服务。使用ShardingSphere时的系统和MySQL交互流程如下：

ShardingSphere是一款分布式的数据库生态系统，它可以将任意数据库转换为分布式数据库，它还可以通过数据分片、弹性伸缩、加密等能力对原有数据库增强。

ShardingSphere主要由ShardingSphere-JDBC和ShardingSphere-Proxy组成。ShardingSphere-JDBC定位为轻量级Java框架，在Java的JDBC层提供额外服务。ShardingSphere-Proxy定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。ShardingSphere-JDBC是基于已经有的库和表进行操作的，会进行数据分片(sharding)和SQL解析(parse)。

ShardingSphere的功能有：数据分片、分布式事务、读写分离、高可用、数据库网关、流量治理、数据迁移、数据加密、数据脱密。

15.创建库和表的小工具

(1)简单总结

(2)创建库和表的工具

(1)简单总结

从项目整体演进的角度：单体项目 -> 流量暴增 -> 查询变慢 -> SQL优化 + 索引 -> 引入缓存 -> 读写分离 -> 垂直拆分 + 水平拆分 -> 分库分表所需要支持的场景(B端和C端) -> 路由设计策略 -> 全局ID(分布式ID)的雪花算法 -> ShardingSphere引入

从数据流动方向的角度：请求数据 -> 业务逻辑处理 -> Mapper生成逻辑SQL -> 选择路由Key -> 选择路由策略 -> 选择具体的数据库 -> 选定具体的表 -> ShardingSphere生成实际的SQL

ShardingSphere并不会帮助我们先把库和表生成好，ShardingSphere是基于已经有的库和表进行操作的，会进行数据分片(sharding)和SQL解析(parse)。所以使用ShardingSphere之前，需要先创建好库和表。

(2)创建库和表的工具

步骤一：配置好分片的策略，两个数据源、8库8表、两个维度的表

也就是8个库会落在两个数据源上，每个库有8张用户维度的表和8张商家维度的表。

shardingstrategyConfig.properties

#数据源的配置，多个数据源参考下边的配置
#数据源1
shardingstrategy.datasources[0].hostName=192.168.10.8
shardingstrategy.datasources[0].port=3307
shardingstrategy.datasources[0].username=root
shardingstrategy.datasources[0].password=Sharding@Master#1990
#数据源2
#shardingstrategy.datasources[1].hostName=xxx.xxx.xx.xxx
#shardingstrategy.datasources[1].port=3306
#shardingstrategy.datasources[1].username=root
#shardingstrategy.datasources[1].password=123456
#分库的配置
#分库分表前的库名
shardingstrategy.originDbName=order_db
#要分的逻辑库总数
shardingstrategy.dbNum=8
#库名的后缀
shardingstrategy.dbSuffix=_
#分表的配置
#每个逻辑库中表的数量
shardingstrategy.tableNumPerDb=8
#表名后缀，一种分表分库维度对应一种后缀，比如C端维度：_by_user_id_  商户端维度：_by_merchant_id_
shardingstrategy.tableSuffix=_sharded_by_user_id_,_sharded_by_merchant_id_

步骤二：加载配置类并交给Spring管理

将配置类shardingstrategyConfig.properties的信息加载到ShardingStrategyConfig类中。

@Data
@Component
@ConfigurationProperties(prefix = "shardingstrategy")
@PropertySource("classpath:shardingstrategyConfig.properties")
public class ShardingStrategyConfig {
    //原始库名，即分库分表前的库名
    private String originDbName;
    //要分的逻辑库总数
    private int dbNum;
    //每个逻辑库中表的数量
    private int tableNumPerDb;
    //库名的后缀
    private String dbSuffix;
    //表名后缀，一种分表分库维度对应一种后缀，比如C端维度：_by_user_id_  商户端维度：_by_merchant_id_
    private List<String> tableSuffix;
    //数据源
    private List<DataSourceConfig> datasources;
}
@Data
public class DataSourceConfig {
    //主机名
    private String hostName;
    //端口号
    private int port;
    //用户名
    private String username;
    //密码
    private String password;
}

步骤三：创建ShardingUtil类生成具体的库和表

@Component
public class ShardingUtil {
    private static final Logger logger = LoggerFactory.getLogger(ShardingUtil.class);
    @Autowired
    private ShardingStrategyConfig shardingStrategyConfig;
    
    //创建库和表
    public void initTables(String sqlPath) {
        //1.校验sqlPath
        if (StringUtils.isBlank(sqlPath)) {
            throw new IllegalArgumentException("sqlPath cannot be empty");
        }
      
        Optional.of(shardingStrategyConfig)
        .map(ShardingStrategyConfig::getDatasources)
        .ifPresent(dataSources -> {
            //逻辑库的索引
            AtomicInteger dbIndex = new AtomicInteger();
            //2.依次处理每个数据源（物理库）
            dataSources.stream().filter(Objects::nonNull).forEach(dataSourceConfig -> {
                //3.创建数据源，建库用临时DataSource
                MysqlDataSource dataSource = buildDataSource(dataSourceConfig);
                JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);
                //4.获取配置的数据库名称
                String originDbName = shardingStrategyConfig.getOriginDbName();
                logger.info("originDbName：[{}]，prepare to process the data source：[{}]", originDbName, dataSource.getUrl());
                //5.每个数据源需要创建多少个逻辑库 逻辑库总数/物理库总数 = 每个物理库上应该创建多少个逻辑库
                int dbNumPerDataSource = shardingStrategyConfig.getDbNum() / dataSources.size();
                //6.依次创建逻辑库
                for (int i = 0; i < dbNumPerDataSource; i++) {
                    //7.创建逻辑数据库
                    String targetDbName = createDatabase(dbIndex, jdbcTemplate, originDbName);
                    //8.在指定的逻辑库中创建table
                    createTables(sqlPath, dataSource, targetDbName);
                }
            });
        });
    }
    //在指定的逻辑db中创建table
    private void createTables(String sqlPath, MysqlDataSource dataSource, String targetDbName) {
        //1.指定建表的逻辑库
        dataSource.setDatabaseName(targetDbName);
        //2.创建建表使用的jdbcTemplate
        JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);
        try {
            //3.拼接建表sql
            String finalTableSql = splicingFinalTableSql(sqlPath);
            //4.执行建表sql
            jdbcTemplate.execute(finalTableSql);
            logger.info("DB[{}] create table complete...", targetDbName);
        } catch (Exception e) {
            logger.error("createTables fail,e:[{}]", e.getMessage());
        }
    }
    //创建逻辑库
    private String createDatabase(AtomicInteger dbIndex, JdbcTemplate jdbcTemplate, String originDbName) {
        //1.拼接要创建的目标数据库名称
        String targetDbName = originDbName + shardingStrategyConfig.getDbSuffix() + (dbIndex.getAndIncrement());
        //2.创建逻辑库
        jdbcTemplate.execute(String.format("CREATE DATABASE IF NOT EXISTS `%s` DEFAULT CHARACTER SET UTF8", targetDbName));
        logger.info("DB[{}]create db complete...", targetDbName);
        return targetDbName;
    }
    //拼接建表sql
    private String splicingFinalTableSql(String sqlPath) throws IOException {
        StringBuilder finalSqlBuilder = new StringBuilder();
        //1.使用流读取sqlPath文件中配置的sql语句
        InputStream inputStream = ShardingUtil.class.getResourceAsStream(sqlPath);
        if (Objects.isNull(inputStream)) {
            throw new IOException("The specified sqlPath file does not exist");
        }
        //2.将流转换成字符串
        String sqlText = IOUtils.toString(inputStream, StandardCharsets.UTF_8);
        for (int i = 0; i < shardingStrategyConfig.getTableNumPerDb(); i++) {
            int tableIndex = i;
            //3.依次处理每条sql
            Optional.of(sqlText.split(";"))
                .ifPresent(sqls -> Arrays.stream(sqls)
                .filter(Objects::nonNull)
                .forEach(sql -> {
                    //4.依次处理配置的表后缀，拼接出相应后缀名的sql
                    shardingStrategyConfig.getTableSuffix().forEach(tableSuffix -> {
                    //5.为sql中的表名拼接后缀
                    String finalTableSql = splicingTableSuffix(sql, tableSuffix + tableIndex);
                    //6.将最终要执行的sql统一拼接起来
                    finalSqlBuilder.append(finalTableSql);
                });
            }));
        }
        return finalSqlBuilder.toString();
    }
    //为sql中的表名拼接后缀
    private String splicingTableSuffix(String sql, String suffix) {
        //1.编写匹配表名的正则表达式，(?i)表示忽略大小写，(?s)表示开启单行模式，即多行sql就像在同一行一样，方便匹配
        Pattern tablePattern = Pattern.compile("(?i)(?s)CREATE\\s+TABLE\\s+(\\S+)");
        StringBuilder sb = new StringBuilder(sql);
        //2.使用正则表达式来匹配表名
        Matcher matcher = tablePattern.matcher(sb);
        if (matcher.find()) {
            //3.在表名后边，拼接上指定的后缀名
            sb.insert(matcher.end(), suffix)
                .append(";")
                .append("\n\n");
            logger.debug("match to table:[{}]", matcher.group(1));
            return sb.toString();
        }
        return "";
    }
    //创建数据源
    private MysqlDataSource buildDataSource(DataSourceConfig dataSourceConfig) {
        MysqlDataSource dataSource = new MysqlDataSource();
        dataSource.setServerName(dataSourceConfig.getHostName());
        dataSource.setPort(dataSourceConfig.getPort());
        dataSource.setUser(dataSourceConfig.getUsername());
        dataSource.setPassword(dataSourceConfig.getPassword());
        dataSource.setCharacterEncoding("utf-8");
        //开启批处理
        dataSource.setAllowMultiQueries(Boolean.TRUE);
        return dataSource;
    }
}

步骤四：通过测试类执行创建库和表

@SpringBootTest
@RunWith(SpringRunner.class)
public class ShardingUtilTest {
    @Autowired
    private ShardingUtil shardingUtil;
    @Test
    public void test_initTables() {
        shardingUtil.initTables("/sql/init.sql");
    }
}

16.ShardingSphere数据分片核心原理

(1)ShardingSphere数据分片的流程

(2)ShardingSphere订单系统流程

由于这里使用的是版本4系列作为例子，所以可以参考下面的官网。

https://shardingsphere.apache.org/document/4.1.1/cn/overview/

(1)ShardingSphere数据分片的流程

一.SQL解析

分为词法解析和语法解析。先通过词法解析器将SQL拆分为一个个不可再分的单词，再使用语法解析器对SQL进行理解，并最终提炼出解析上下文。解析上下文包括表、选择项、排序项、分组项、聚合函数、分页信息、查询条件以及可能需要修改的占位符的标记。执行器优化合并和优化分片条件，如OR等。

二.SQL路由

根据解析上下文匹配用户配置的分片策略，并生成路由路径。目前支持分片路由和广播路由。

三.SQL改写

将SQL改写为在真实数据库中可以正确执行的语句，SQL改写分为正确性改写和优化改写。

四.SQL执行

通过多线程执行器异步执行。

五.结果归并

将多个执行结果集归并以便于通过统一的JDBC接口输出，结果归并包括流式归并、内存归并和使用装饰者模式的追加归并这几种方式。

(2)ShardingSphere订单系统流程

17.C端ShardingSphere分片策略实现

(1)在application.properties进行分库分表配置

(2)编写C端维度分库路由算法类

(3)编写C端维度分表路由算法类

(4)创建订单的具体实现

(1)在application.properties进行分库分表配置

以下是基于Spring Boot的规则配置：配置了8主8从，8个主库在数据源1—192.168.10.8:3307，8个从库在数据源2—192.168.10.8:3308。

//参考：https://shardingsphere.apache.org/document/4.1.1/cn/manual/sharding-jdbc/usage/sharding/
#分库分表配置
#打印执行的数据库以及语句
spring.shardingsphere.props.sql.show=true
spring.shardingsphere.datasource.names=master0,slave0,master1,slave1,master2,slave2,master3,slave3,master4,slave4,master5,slave5,master6,slave6,master7,slave7
spring.shardingsphere.datasource.master0.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master0.url=jdbc:mysql://192.168.10.8:3307/order_db_0?characterEncoding=utf-8
spring.shardingsphere.datasource.master0.username=root
spring.shardingsphere.datasource.master0.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave0.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave0.url=jdbc:mysql://192.168.10.8:3308/order_db_0?characterEncoding=utf-8
spring.shardingsphere.datasource.slave0.username=root
spring.shardingsphere.datasource.slave0.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master1.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master1.url=jdbc:mysql://192.168.10.8:3307/order_db_1?characterEncoding=utf-8
spring.shardingsphere.datasource.master1.username=root
spring.shardingsphere.datasource.master1.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave1.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave1.url=jdbc:mysql://192.168.10.8:3308/order_db_1?characterEncoding=utf-8
spring.shardingsphere.datasource.slave1.username=root
spring.shardingsphere.datasource.slave1.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master2.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master2.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master2.url=jdbc:mysql://192.168.10.8:3307/order_db_2?characterEncoding=utf-8
spring.shardingsphere.datasource.master2.username=root
spring.shardingsphere.datasource.master2.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave2.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave2.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave2.url=jdbc:mysql://192.168.10.8:3308/order_db_2?characterEncoding=utf-8
spring.shardingsphere.datasource.slave2.username=root
spring.shardingsphere.datasource.slave2.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master3.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master3.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master3.url=jdbc:mysql://192.168.10.8:3307/order_db_3?characterEncoding=utf-8
spring.shardingsphere.datasource.master3.username=root
spring.shardingsphere.datasource.master3.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave3.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave3.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave3.url=jdbc:mysql://192.168.10.8:3308/order_db_3?characterEncoding=utf-8
spring.shardingsphere.datasource.slave3.username=root
spring.shardingsphere.datasource.slave3.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master4.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master4.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master4.url=jdbc:mysql://192.168.10.8:3307/order_db_4?characterEncoding=utf-8
spring.shardingsphere.datasource.master4.username=root
spring.shardingsphere.datasource.master4.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave4.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave4.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave4.url=jdbc:mysql://192.168.10.8:3308/order_db_4?characterEncoding=utf-8
spring.shardingsphere.datasource.slave4.username=root
spring.shardingsphere.datasource.slave4.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master5.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master5.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master5.url=jdbc:mysql://192.168.10.8:3307/order_db_5?characterEncoding=utf-8
spring.shardingsphere.datasource.master5.username=root
spring.shardingsphere.datasource.master5.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave5.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave5.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave5.url=jdbc:mysql://192.168.10.8:3308/order_db_5?characterEncoding=utf-8
spring.shardingsphere.datasource.slave5.username=root
spring.shardingsphere.datasource.slave5.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master6.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master6.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master6.url=jdbc:mysql://192.168.10.8:3307/order_db_6?characterEncoding=utf-8
spring.shardingsphere.datasource.master6.username=root
spring.shardingsphere.datasource.master6.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave6.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave6.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave6.url=jdbc:mysql://192.168.10.8:3308/order_db_6?characterEncoding=utf-8
spring.shardingsphere.datasource.slave6.username=root
spring.shardingsphere.datasource.slave6.password=Sharding@Slave#1990
spring.shardingsphere.datasource.master7.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.master7.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master7.url=jdbc:mysql://192.168.10.8:3307/order_db_7?characterEncoding=utf-8
spring.shardingsphere.datasource.master7.username=root
spring.shardingsphere.datasource.master7.password=Sharding@Master#1990
spring.shardingsphere.datasource.slave7.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.slave7.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave7.url=jdbc:mysql://192.168.10.8:3308/order_db_7?characterEncoding=utf-8
spring.shardingsphere.datasource.slave7.username=root
spring.shardingsphere.datasource.slave7.password=Sharding@Slave#1990
#用于多分片键的复合分片场景
#C端order_info分表策略分片策略
#分片列名称，多个列以逗号分隔
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.database-strategy.complex.sharding-columns=order_no,user_id
#复合分片算法类名称，该类需实现ComplexKeysShardingAlgorithm接口并提供无参数的构造器
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.database-strategy.complex.algorithm-class-name=com.demo.sharding.order.sharding.algorithm.OrderDbShardingByUserAlgorithm
#C端分表策略
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.actual-data-nodes=master$->{0..7}.order_info_sharded_by_user_id_$->{0..7}
#分片字段
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.table-strategy.complex.sharding-columns=order_no,user_id
#order_info表分片策略类
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.table-strategy.complex.algorithm-class-name=com.demo.sharding.order.sharding.algorithm.OrderTableShardingByUserAlgorithm
#主键名称，缺省表示不使用自增主键生成器
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.key-generator.column=id
#主键生成器类型，内置类型：SNOWFLAKE/UUID
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.key-generator.type=SNOWFLAKE
#工作机器 id
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.key-generator.props.worker.id=${workerId}
#时钟回拨可以容忍的毫秒数，默认10ms
spring.shardingsphere.sharding.tables.order_info_sharded_by_user_id_.key-generator.props.max.tolerate.time.difference.milliseconds=5
#C端order_item_detail分表策略分片策略
#分片列名称，多个列以逗号分隔
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.database-strategy.complex.sharding-columns=order_no,user_id
#复合分片算法类名称，该类需实现ComplexKeysShardingAlgorithm接口并提供无参数的构造器
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.database-strategy.complex.algorithm-class-name=com.demo.sharding.order.sharding.algorithm.OrderDbShardingByUserAlgorithm
#C端分表策略
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.actual-data-nodes=master$->{0..7}.order_item_detail_sharded_by_user_id_$->{0..7}
#分片字段
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.table-strategy.complex.sharding-columns=order_no,user_id
#order_item_detail表分片策略类
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.table-strategy.complex.algorithm-class-name=com.demo.sharding.order.sharding.algorithm.OrderTableShardingByUserAlgorithm
#主键名称，缺省表示不使用自增主键生成器
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.key-generator.column=id
#主键生成器类型，内置类型：SNOWFLAKE/UUID
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.key-generator.type=SNOWFLAKE
#工作机器 id
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.key-generator.props.worker.id=${workerId}
#时钟回拨可以容忍的毫秒数，默认10ms
spring.shardingsphere.sharding.tables.order_item_detail_sharded_by_user_id_.key-generator.props.max.tolerate.time.difference.milliseconds=5

其中官网中关于数据分片的数据项配置说明如下：

//参考：https://shardingsphere.apache.org/document/4.1.1/cn/manual/sharding-jdbc/configuration/config-spring-boot/
spring.shardingsphere.datasource.names= #数据源名称，多数据源以逗号分隔
spring.shardingsphere.datasource.<data-source-name>.type= #数据库连接池类名称
spring.shardingsphere.datasource.<data-source-name>.driver-class-name= #数据库驱动类名
spring.shardingsphere.datasource.<data-source-name>.url= #数据库url连接
spring.shardingsphere.datasource.<data-source-name>.username= #数据库用户名
spring.shardingsphere.datasource.<data-source-name>.password= #数据库密码
spring.shardingsphere.datasource.<data-source-name>.xxx= #数据库连接池的其它属性
spring.shardingsphere.sharding.tables.<logic-table-name>.actual-data-nodes= #由数据源名 + 表名组成，以小数点分隔。多个表以逗号分隔，支持inline表达式。缺省表示使用已知数据源与逻辑表名称生成数据节点，用于广播表（即每个库中都需要一个同样的表用于关联查询，多为字典表）或只分库不分表且所有库的表结构完全一致的情况
#分库策略，缺省表示使用默认分库策略，以下的分片策略只能选其一
#用于单分片键的标准分片场景
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.standard.sharding-column= #分片列名称
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.standard.precise-algorithm-class-name= #精确分片算法类名称，用于=和IN。该类需实现PreciseShardingAlgorithm接口并提供无参数的构造器
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.standard.range-algorithm-class-name= #范围分片算法类名称，用于BETWEEN，可选。该类需实现RangeShardingAlgorithm接口并提供无参数的构造器
#用于多分片键的复合分片场景
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.complex.sharding-columns= #分片列名称，多个列以逗号分隔
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.complex.algorithm-class-name= #复合分片算法类名称。该类需实现ComplexKeysShardingAlgorithm接口并提供无参数的构造器
#行表达式分片策略
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.inline.sharding-column= #分片列名称
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.inline.algorithm-expression= #分片算法行表达式，需符合groovy语法
#Hint分片策略
spring.shardingsphere.sharding.tables.<logic-table-name>.database-strategy.hint.algorithm-class-name= #Hint分片算法类名称。该类需实现HintShardingAlgorithm接口并提供无参数的构造器
#分表策略，同分库策略
spring.shardingsphere.sharding.tables.<logic-table-name>.table-strategy.xxx= #省略
spring.shardingsphere.sharding.tables.<logic-table-name>.key-generator.column= #自增列名称，缺省表示不使用自增主键生成器
spring.shardingsphere.sharding.tables.<logic-table-name>.key-generator.type= #自增列值生成器类型，缺省表示使用默认自增列值生成器。可使用用户自定义的列值生成器或选择内置类型：SNOWFLAKE/UUID
spring.shardingsphere.sharding.tables.<logic-table-name>.key-generator.props.<property-name>= #属性配置, 注意：使用SNOWFLAKE算法，需要配置worker.id与max.tolerate.time.difference.milliseconds属性。若使用此算法生成值作分片值，建议配置max.vibration.offset属性
spring.shardingsphere.sharding.binding-tables[0]= #绑定表规则列表
spring.shardingsphere.sharding.binding-tables[1]= #绑定表规则列表
spring.shardingsphere.sharding.binding-tables[x]= #绑定表规则列表
spring.shardingsphere.sharding.broadcast-tables[0]= #广播表规则列表
spring.shardingsphere.sharding.broadcast-tables[1]= #广播表规则列表
spring.shardingsphere.sharding.broadcast-tables[x]= #广播表规则列表
spring.shardingsphere.sharding.default-data-source-name= #未配置分片规则的表将通过默认数据源定位
spring.shardingsphere.sharding.default-database-strategy.xxx= #默认数据库分片策略，同分库策略
spring.shardingsphere.sharding.default-table-strategy.xxx= #默认表分片策略，同分表策略
spring.shardingsphere.sharding.default-key-generator.type= #默认自增列值生成器类型，缺省将使用org.apache.shardingsphere.core.keygen.generator.impl.SnowflakeKeyGenerator。可使用用户自定义的列值生成器或选择内置类型：SNOWFLAKE/UUID
spring.shardingsphere.sharding.default-key-generator.props.<property-name>= #自增列值生成器属性配置, 比如SNOWFLAKE算法的worker.id与max.tolerate.time.difference.milliseconds
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.master-data-source-name= #详见读写分离部分
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[0]= #详见读写分离部分
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[1]= #详见读写分离部分
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[x]= #详见读写分离部分
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.load-balance-algorithm-class-name= #详见读写分离部分
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.load-balance-algorithm-type= #详见读写分离部分
spring.shardingsphere.props.sql.show= #是否开启SQL显示，默认值: false
spring.shardingsphere.props.executor.size= #工作线程数量，默认值: CPU核数

(2)编写C端维度分库路由算法类

该算法类已配置在application.properties中。

//C端维度分库路由算法类
public class OrderDbShardingByUserAlgorithm implements ComplexKeysShardingAlgorithm<Comparable<?>> {
    @Override
    public Collection<String> doSharding(Collection<String> dbs, ComplexKeysShardingValue<Comparable<?>> shardingValue) {
        Collection<Comparable<?>> orderNos = shardingValue.getColumnNameAndShardingValuesMap().get("order_no");
        Collection<Comparable<?>> userIds = shardingValue.getColumnNameAndShardingValuesMap().get("user_id");
        Set<String> actualDbNames = null;
        if (CollectionUtils.isNotEmpty(orderNos)) {
            actualDbNames = orderNos.stream()
                .map(orderNo -> getActualDbName(String.valueOf(orderNo), dbs))
                .collect(Collectors.toSet());
        } else if (CollectionUtils.isNotEmpty(userIds)) {
            actualDbNames = userIds.stream()
                .map(userId -> getActualDbName(String.valueOf(userId), dbs))
                .collect(Collectors.toSet());
        }
        return actualDbNames;
    }
    public String getActualDbName(String shardingValue, Collection<String> dbs) {
        //获取userId后三位
        String userIdSuffix = StringUtils.substring(shardingValue, shardingValue.length() - 3);
        //使用userId后三位进行路由
        int dbSuffix = userIdSuffix.hashCode() % dbs.size();
        for (String db : dbs) {
            if (db.endsWith(String.valueOf(dbSuffix))) {
                return db;
            }
        }
        return null;
    }
}

(3)编写C端维度分表路由算法类

该算法类已配置在application.properties中。

//C端维度分表路由算法类
public class OrderTableShardingByUserAlgorithm implements ComplexKeysShardingAlgorithm<Comparable<?>> {
    @Override
    public Collection<String> doSharding(Collection<String> tables, ComplexKeysShardingValue<Comparable<?>> shardingValue) {
        Collection<Comparable<?>> orderNos = shardingValue.getColumnNameAndShardingValuesMap().get("order_no");
        Collection<Comparable<?>> userIds = shardingValue.getColumnNameAndShardingValuesMap().get("user_id");
        Set<String> actualTableNames = null;
        if (CollectionUtils.isNotEmpty(orderNos)) {
            actualTableNames = orderNos.stream()
                .map(orderNo -> getActualTableName(String.valueOf(orderNo), tables))
                .collect(Collectors.toSet());
        } else if (CollectionUtils.isNotEmpty(userIds)) {
            actualTableNames = userIds.stream()
                .map(userId -> getActualTableName(String.valueOf(userId), tables))
                .collect(Collectors.toSet());
        }
        return actualTableNames;
    }
    public String getActualTableName(String shardingValue, Collection<String> tables) {
        //获取userId后三位
        String userIdSuffix = StringUtils.substring(shardingValue, shardingValue.length() - 3);
        //使用userId后三位进行路由
        int tableSuffix = userIdSuffix.hashCode() / tables.size() % tables.size();
        for (String table : tables) {
            if (table.endsWith(String.valueOf(tableSuffix))) {
                return table;
            }
        }
        return null;
    }
}

(4)创建订单的具体实现

@RestController
@RequestMapping(value = "/user/order")
public class UserOrderController {
    @Autowired
    private UserOrderInfoService userOrderInfoService;
    ...
    //创建订单
    @PostMapping("/generateOrder")
    public OperationResponse generateOrder(@RequestBody UserOrderInfoRequest userOrderInfoRequest) {
        try {
            long startTime = System.currentTimeMillis();
            userOrderInfoService.generateOrder(userOrderInfoRequest);
            long endTime = System.currentTimeMillis();
            log.info("创建用户订单耗时：[{}]", (endTime - startTime));
            return OperationResponse.success(OrderCode.ADD_ORDER_SUCCESS.getDesc());
        } catch (BaseException e) {
            return OperationResponse.error(e.getMessage());
        } catch (Exception e) {
            log.error("generateOrder error: [{}]", e.getMessage(), e);
            return OperationResponse.error(OrderCode.ADD_ORDER_ERROR.getDesc());
        }
    }
    ...
}
//用户订单服务实现
@Service
public class UserOrderInfoServiceImpl implements UserOrderInfoService {
    @Autowired
    private UserOrderRepository userOrderRepository;
    ...
    @Override
    public void generateOrder(UserOrderInfoRequest userOrderInfoRequest) {
        //1.入参校验
        OrderValidation.checkVerifyOrderRequest(userOrderInfoRequest);
        //2.添加订单信息
        OrderInfo orderInfo = orderConvertor.dtoConvertOrderInfo(userOrderInfoRequest);
        //3.添加订单详情
        List<OrderItemDetail> orderItemDetailList = userOrderInfoRequest.getOrderItemDetailList();
        //4.生成订单号
        String orderNo = GenerateOrderNoUtils.getOrderNo(orderInfo.getUserId(), orderInfo.getMerchantId());
        //5.为订单和订单明细设置订单号
        orderInfo.setOrderNo(orderNo);
        orderItemDetailList.forEach(orderItemDetail -> orderItemDetail.setOrderNo(orderInfo.getOrderNo()));
        //6.保存订单信息
        userOrderRepository.generateOrderInfo(orderInfo, orderItemDetailList);
        ...
    }
    ...
}
public class GenerateOrderNoUtils {
    ...
    //生成订单单号编码(调用方法)，网站中该用户唯一ID 防止重复
    public static String getOrderNo(Long userId, Long merchantId) {
        return getOrderIdKey(String.valueOf(userId), String.valueOf(merchantId));
    }
    
    private static String getOrderIdKey(String userId, String merchantId) {
        return "10" + getDateTimeKey() + getAutoNoKey() + toCode(userId, merchantId);
    }
    
    //生成时间戳
    private static String getDateTimeKey() {
        return DateFormatUtils.format(new Date(), "yyMMdd");
    }
    
    private static String getAutoNoKey() {
        long random = getRandom(6);
        return String.valueOf(genNo(random, 5));
    }
    
    //根据ID进行加密 + 加随机数组成固定长度编码：3位随机数 + 商家ID后3位 + 用户ID后3位
    private static String toCode(String userId, String merchantId) {
        String userIdSubstring = userId.substring(userId.length() - 3);
        String merchantIdSubstring = merchantId.substring(merchantId.length() - 3);
        long random = getRandom(3);
        return random + merchantIdSubstring + userIdSubstring;
    }
    ...
}
@Repository
public class UserOrderRepository {
    ...
    @Transactional(rollbackFor = Exception.class)
    public void generateOrderInfo(OrderInfo orderInfo, List<OrderItemDetail> orderItemDetailList) {
        //1.保存订单信息
        userOrderInfoMapper.insertSelective(orderInfo);
        //2.批量保存订单明细
        userOrderItemDetailMapper.batchInsert(orderItemDetailList);
    }
    ...
}

而在userOrderInfoMapper.xml和userOrderItemDetailMapper.xml中已变为逻辑SQL。这些逻辑SQL会交给ShardingSphere-JDBC进行处理：解析SQL、进行拦截路由拼装、生成具体的SQL。ShardingSphere-JDBC会最终定位到具体的哪个库和哪个表中执行具体的SQL。

####################################userOrderInfoMapper.xml####################################
<insert id="insertSelective" parameterType="com.demo.sharding.order.domain.entity.OrderInfo" keyProperty="orderInfo.id"
        useGeneratedKeys="true">
    insert into order_info_sharded_by_user_id_
    <trim prefix="(" suffix=")" suffixOverrides=",">
      ...
    </trim>
</insert>
####################################userOrderItemDetailMapper.xml####################################
<insert id="batchInsert">
    insert into order_item_detail_sharded_by_user_id_
    (order_no,
    product_id,category_id,goods_num,goods_price,goods_amount,discount_amount,discount_id,create_user,update_user)
    values
    <foreach collection="records" item="record" separator=",">
        (#{record.orderNo,jdbcType=VARCHAR}, #{record.productId,jdbcType=BIGINT},
        #{record.categoryId,jdbcType=BIGINT}, #{record.goodsNum,jdbcType=BIGINT},
        #{record.goodsPrice,jdbcType=DECIMAL},#{record.goodsAmount,jdbcType=DECIMAL},
        #{record.discountAmount,jdbcType=DECIMAL}, #{record.discountId,jdbcType=BIGINT},
        #{record.createUser,jdbcType=BIGINT},#{record.updateUser,jdbcType=BIGINT})
    </foreach>
</insert>

18.C端ShardingSphere读写分离实现

只需在application.properties进行读写分离配置：

#主从配置-读写分离
spring.shardingsphere.sharding.master-slave-rules.master0.master-data-source-name=master0
spring.shardingsphere.sharding.master-slave-rules.master0.slave-data-source-names=slave0
spring.shardingsphere.sharding.master-slave-rules.master1.master-data-source-name=master1
spring.shardingsphere.sharding.master-slave-rules.master1.slave-data-source-names=slave1
spring.shardingsphere.sharding.master-slave-rules.master2.master-data-source-name=master2
spring.shardingsphere.sharding.master-slave-rules.master2.slave-data-source-names=slave2
spring.shardingsphere.sharding.master-slave-rules.master3.master-data-source-name=master3
spring.shardingsphere.sharding.master-slave-rules.master3.slave-data-source-names=slave3
spring.shardingsphere.sharding.master-slave-rules.master4.master-data-source-name=master4
spring.shardingsphere.sharding.master-slave-rules.master4.slave-data-source-names=slave4
spring.shardingsphere.sharding.master-slave-rules.master5.master-data-source-name=master5
spring.shardingsphere.sharding.master-slave-rules.master5.slave-data-source-names=slave5
spring.shardingsphere.sharding.master-slave-rules.master6.master-data-source-name=master6
spring.shardingsphere.sharding.master-slave-rules.master6.slave-data-source-names=slave6
spring.shardingsphere.sharding.master-slave-rules.master7.master-data-source-name=master7
spring.shardingsphere.sharding.master-slave-rules.master7.slave-data-source-names=slave7

其中官网中关于读写分离的数据项配置说明如下：

//参考：https://shardingsphere.apache.org/document/4.1.1/cn/manual/sharding-jdbc/configuration/config-spring-boot/
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.master-data-source-name= #主库数据源名称
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[0]= #从库数据源名称列表
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[1]= #从库数据源名称列表
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.slave-data-source-names[x]= #从库数据源名称列表
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.load-balance-algorithm-class-name= #从库负载均衡算法类名称。该类需实现MasterSlaveLoadBalanceAlgorithm接口且提供无参数构造器
spring.shardingsphere.sharding.master-slave-rules.<master-slave-data-source-name>.load-balance-algorithm-type= #从库负载均衡算法类型，可选值：ROUND_ROBIN，RANDOM。若`load-balance-algorithm-class-name`存在则忽略该配置
spring.shardingsphere.props.sql.show= #是否开启SQL显示，默认值: false
spring.shardingsphere.props.executor.size= #工作线程数量，默认值: CPU核数
spring.shardingsphere.props.check.table.metadata.enabled= #是否在启动时检查分表元数据一致性，默认值: false

19.异构订单实现

要实现异构订单，就需要在C端创建完订单后，发送消息到MQ，然后由B端进行消费。

@Service
public class UserOrderInfoServiceImpl implements UserOrderInfoService {
    ...
    @Override
    public void generateOrder(UserOrderInfoRequest userOrderInfoRequest) {
        //1.入参校验
        OrderValidation.checkVerifyOrderRequest(userOrderInfoRequest);
        //2.添加订单信息
        OrderInfo orderInfo = orderConvertor.dtoConvertOrderInfo(userOrderInfoRequest);
        //3.添加订单详情
        List<OrderItemDetail> orderItemDetailList = userOrderInfoRequest.getOrderItemDetailList();
        //4.生成订单号
        String orderNo = GenerateOrderNoUtils.getOrderNo(orderInfo.getUserId(), orderInfo.getMerchantId());
        //5.为订单和订单明细设置订单号
        orderInfo.setOrderNo(orderNo);
        orderItemDetailList.forEach(orderItemDetail -> orderItemDetail.setOrderNo(orderInfo.getOrderNo()));
        //6.保存订单信息
        userOrderRepository.generateOrderInfo(orderInfo, orderItemDetailList);
        //7.构建消息体
        OrderSyncMessage orderSyncMessage = OrderSyncMessage.builder()
            .requestSource(RequestSource.C)
            .orderOperateType(OrderOperateType.add)
            .orderNo(orderInfo.getOrderNo())
            .build();
        //8.发送mq消息
        rocketMQProducer.reliablySend(topic, orderSyncMessage, orderSyncMessage.getOrderNo(), obj -> {
            OrderSyncMessage message = (OrderSyncMessage) obj;
            // 这里可以将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker
            log.info("generateOrder send mq message failed, store the mq message to db，orderNo:[{}],message:[{}]", message.getOrderNo(), message);
        });
    }
    ...
}

消费消息创建异构订单：

@Component
@RocketMQMessageListener(consumerGroup = "${order.sync.consumer.group}", topic = "${order.topic}")
public class OrderSyncConsumer implements RocketMQListener<OrderSyncMessage> {
    @Autowired
    private MerchantOrderRepository merchantOrderRepository;
    @Autowired
    private UserOrderRepository userOrderRepository;
    
    @Override
    public void onMessage(OrderSyncMessage orderSyncMessage) {
        log.info("received message，start processing,orderNo:[{}],message:[{}]", orderSyncMessage.getOrderNo(), orderSyncMessage);
        //1.check请求来源
        if (Objects.isNull(orderSyncMessage.getRequestSource())) {
            log.error("requestSource can not be empty，orderNo:[{}]", orderSyncMessage.getOrderNo());
            return;
        }
        //2.获取订单源数据
        OrderDetailVO orderDetail = getOrderDetail(orderSyncMessage.getOrderNo(), orderSyncMessage.getRequestSource());
        //3.如果订单为空，打印日志并抛出异常，从而等待rocketMQ下次重试
        if (Objects.isNull(orderDetail)) {
            //打印错误日志
            log.error("orderDetail not exist,orderNo:[{}]", orderSyncMessage.getOrderNo());
            //抛出异常，等待rocketMQ下次重试
            throw new NullPointerException("orderDetail is null,orderNo:[{}]" + orderSyncMessage.getOrderNo());
        }
        //4.获取要处理的目标源
        RequestSource target = RequestSource.C.equals(orderSyncMessage.getRequestSource()) ? RequestSource.B : RequestSource.C;
        //5.同步订单数据的处理,即异构一份订单数据到目标源 或 同步订单状态到目标源
        if (OrderOperateType.add.equals(orderSyncMessage.getOrderOperateType())) {
            //异构一份订单数据到目标源
            syncOrderInfo(orderSyncMessage, orderDetail, target);
        } else if (OrderOperateType.updateOrderStatus.equals(orderSyncMessage.getOrderOperateType())) {
            //同步订单状态到目标源
            updateOrderStatus(orderDetail.getOrderNo(), orderDetail.getOrderStatus(), target);
        }
    }
    
    //异构一份订单数据到目标源
    private void syncOrderInfo(OrderSyncMessage orderSyncMessage, OrderDetailVO orderDetail, RequestSource target) {
        //1.幂等处理，目标订单存在则跳过
        OrderDetailVO targetOrder = getOrderDetail(orderSyncMessage.getOrderNo(), target);
        if (Objects.nonNull(targetOrder)) {
            log.info("targetOrder existed,orderNo:[{}]", orderSyncMessage.getOrderNo());
            return;
        }
        //2.同步订单信息到目标源
        syncOrderInfo(orderDetail, target);
    }
    //同步订单信息到目标源
    private void syncOrderInfo(OrderDetailVO orderDetail, RequestSource target) {
        //1.拷贝数据 orderDetail -> orderInfo
        OrderInfo orderInfo = new OrderInfo();
        BeanUtils.copyProperties(orderDetail, orderInfo);
        //2.转换类型 OrderItemDetailDto -> OrderItemDetail
        List<OrderItemDetail> orderItemDetailList = convertOrderItemDetails(orderDetail.getOrderItemDetails());
        //3.异构订单到商家,目前只有从C端下单，异构到B端的业务
        if (RequestSource.B.equals(target)) {
            //异构订单到商家
            merchantOrderRepository.syncOrderInfo(orderInfo, orderItemDetailList);
        }
    }
    //获取订单详情
    private OrderDetailVO getOrderDetail(String orderNo, RequestSource requestSource) {
        if (RequestSource.C.equals(requestSource)) {
            return userOrderRepository.getOrderDetail(orderNo);
        } else if (RequestSource.B.equals(requestSource)) {
            return merchantOrderRepository.getOrderDetail(orderNo);
        }
        return null;
    }
    //同步订单状态到目标源
    private void updateOrderStatus(String orderNo, Integer orderStatus, RequestSource requestSource) {
        if (RequestSource.C.equals(requestSource)) {
            userOrderRepository.updateStatus(orderNo, orderStatus);
        } else if (RequestSource.B.equals(requestSource)) {
            merchantOrderRepository.updateStatus(orderNo, orderStatus);
        }
    }
    //将OrderItemDetailDto类型 转换为 OrderItemDetail类型
    private List<OrderItemDetail> convertOrderItemDetails(List<OrderItemDetailDto> orderItemDetailDtos) {
        List<OrderItemDetail> orderItemDetailList = new ArrayList<>();
        for (OrderItemDetailDto itemDetail : orderItemDetailDtos) {
            OrderItemDetail orderItemDetail = new OrderItemDetail();
            BeanUtils.copyProperties(itemDetail, orderItemDetail);
            orderItemDetailList.add(orderItemDetail);
        }
        return orderItemDetailList;
    }
}

20.单库亿级数据怎么迁移到多库多表上

(1)单库单表的亿级数据如何迁移到8库8表上

(2)全量同步的处理

(3)数据校验的处理

(4)增量同步的处理

(5)增量同步的问题

(1)单库单表的亿级数据如何迁移到8库8表上

数据迁移 -> 全量同步
    数据校验的问题
    断点续传的问题
数据迁移 -> 增量同步

(2)全量同步的处理

全量同步，指的就是将旧库的数据，通过ShardingShpere的路由，同步迁移到新库当中。单库的数据特别大，有上亿条数据，我们并不是一下子全部查出来，而是分批次去查询。

全量同步的处理流程如下：

每当需要进行一次全量同步时，就会创建一条迁移记录。这条迁移记录其实就代表着一次全量同步的任务，对线上的数据进行迁移可能会执行很多次这种全量同步的任务。在一次全量同步的任务中，会对全量数据进行循环式、分批次、每次尝试查询500条数据。如果能从单库单表查询到数据，就会添加一条该批次的迁移明细记录。接着可以对每次查询出来的500条数据，按照时间等条件进行过滤。然后将过滤出来的数据按表进行分组，批量插入到多库多表中。最后更新该批次的迁移明细记录的状态为同步状态。如果在对全量数据进行循环式、每次尝试查询500条数据时，终于查不到数据了，则更新本次全量同步任务对应的迁移记录的状态为同步状态。