一、Sharding-JDBC 分库分表入门（上）

转x33g5p2x  于2021-12-30 转载在 其他  
字(15.4k)|赞(0)|评价(0)|浏览(260)

1.概述

1.1分库分表是什么

小明是一家初创电商平台的开发人员，他负责卖家模块的功能开发，其中涉及了店铺、商品的相关业务，设计如下数据库：

通过以下SQL能够获取到商品相关的店铺信息、地理区域信息：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 
FROM [商品信息] p 
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] 
WHERE p.id = ?

形成类似以下列表展示：

随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化迫在眉睫。分析一下问题出现在哪儿呢？ 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。   

方案1：通过提升服务器硬件能力来提高数据处理能力，比如增加存储容量 、CPU等，这种方案成本很高，并且如果瓶颈在MySQL本身那么提高硬件也是有很的。

方案2： 把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的，如下图：将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库拆分的方法来解决数据库的性能问题。

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成**，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目****的。**

1.2分库分表的方式

分库分表包括分库和分表两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式。

1.2.1垂直分表

下边通过一个商品查询的案例讲解垂直分表。通常在商品列表中是不显示商品详情信息的，如下图：

用户在浏览商品列表时，只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问频次较低，且该字段存储占用空间较大，访问单个数据IO时间较长；商品信息中商品名称、商品图片、商品价格等其他字段数据访问频次较高。

由于这两种数据的特性不一样，因此考虑将商品信息表拆分如下。将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中。

商品列表可采用以下sql：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 
FROM [商品信息] p 
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] 
WHERE...ORDER BY...LIMIT...

需要获取商品描述时，再通过以下sql获取：

SELECT * 
FROM [商品描述] 
WHERE [商品ID] = ?

小明进行的这一步优化，就叫垂直分表。垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。

**        **它带来的提升是：
        1.为了避免IO争抢并减少锁表的几率，查看详情的用户与商品信息浏览互不影响；

        2.充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累。
        一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大的BLOB或是TEXT。例如上例中的商品描述。所以，当表数据量很大时，可以将表按字段切开，将热门字段、冷门字段分开放****置在不同库中，这些库可以放在不同的存储设备上，避免IO争抢。垂直切分带来的性能提升主要集中在热门数据的操作效率上，而且磁盘争用情况减少。

        通常我们按以下原则进行垂直拆分:
        1. 把不常用的字段单独放在一张表;

        2. 把text，blob等大字段拆分出来放在附表中;
        3. 经常组合查询的列放在一张表中。

1.2.2垂直分库

通过垂直分表性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限制在一台服务器，库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同的服务器上，因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

经过思考，他把原有的SELLER_DB(卖家库)，分为了PRODUCT_DB(商品库)和STORE_DB(店铺库)，并把这两个库分散到不同服务器，如下图： 

由于商品信息与商品描述业务耦合度较高，因此一起被存放在PRODUCT_DB(商品库)；而店铺信息相对独立，因此单独被存放在STORE_DB(店铺库)。 小明进行的这一步优化，就叫垂直分库。垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。它带来的提升是：
        解决业务层面的耦合，业务清晰；

        能对不同业务的数据进行分级管理、维护、监控、扩展等；
        高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈。

        垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题。

1.2.3水平分库

经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计，目前有8w店铺，每个店铺平均150个不同规格的商品，再算上增长，那商品数量得往1500w+上预估，并且PRODUCT_DB(商品库)属于访问非常频繁的资源，单台服务器已经无法支撑。此时该如何优化？

     再次分库？但是从业务角度分析，目前情况已经无法再次垂直分库。 尝试水平分库，将店铺ID为单数的和店铺ID为双数的商品信息分别放在两个库中。

        也就是说，要操作某条数据，先分析这条数据所属的店铺ID。如果店铺ID为双数，将此操作映射至RRODUCT_DB1(商品库1)；如果店铺ID为单数，将操作映射至RRODUCT_DB2(商品库2)。此操作要访问数据库名称的表达式为RRODUCT_DB[店铺ID%2 + 1]。 小明进行的这一步优化，就叫水平分库。水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。它带来的提升是：

  • 解决了单库大数据，高并发的性能瓶颈。
  • 提高了系统的稳定性及可用性。

         当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度。

1.2.4水平分表

按照水平分库的思路对他把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分，其目的也是为解决单表数据量大的问题，如下图：

与水平分库的思路类似，不过这次操作的目标是表，商品信息及商品描述被分成了两套表。如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1]。 小明进行的这一步优化，就叫水平分表。****水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。 它带来的提升是：

  • 优化单一表数据量过大而产生的性能问题；
  • 避免IO争抢并减少锁表的几率。

库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能。

1.2.5小结

本章介绍了分库分表的各种方式，它们分别是垂直分表、垂直分库、水平分库和水平分表。
        垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失。

        垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。
        水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。

        水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。
        

        一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。

1.3分库分表带来的问题

分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。

1.3.1事务一致性问题

由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。

1.3.2跨界店关联查询

在没有分库前，我们检索商品时可以通过以下SQL对店铺信息进行关联查询：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 
FROM [商品信息] p 
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] 
WHERE...ORDER BY...LIMIT...

但垂直分库后**[商品信息]和[店铺信息]**不在一个数据库，甚至不在一台服务器，无法进行关联查询。可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据，最后将获得到的数据进行拼装。

1.3.3跨界店分页、排序函数

跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。如，进行水平分库后的商品库，按ID倒序排序分页，取第一页：

以上流程是取第一页的数据，性能影响不大，但由于商品信息的分布在各数据库的数据可能是随机的，如果是取第N页，需要将所有节点前N页数据都取出来合并，再进行整体的排序，操作效率可想而知。所以请求页数越大，系统的性能也会越差。 在使用Max、Min、Sum、Count之类的函数进行计算的时候，与排序分页同理，也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。

1.3.4主键避重

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。

1.3.5公共表

实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。例子中地****理区域表也属于此类型。 可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。 由于分库分表之后，数据被分散在不同的数据库、服务器。因此，对数据的操作也就无法通过常规方式完成，并且它还带来了一系列的问题。好在，这些问题不是所有都需要我们在应用层面上解决，市面上有很多中间件可供我们选择，其中Sharding-JDBC使用流行度较高，我们来了解一下它。

1.4Sharding-JDBC介绍

1.4.1Sharding-JDBC介绍

Sharding-JDBC是当当网研发的开源分布式数据库中间件，从3.0开始Sharding-JDBC被包含在Sharding-Sphere中，之后该项目进入进入Apache孵化器，4.0版本之后的版本为Apache版本。
**        ShardingSphere**是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

        

        官方地址：https://shardingsphere.apache.org/document/current/cn/overview/
        咱们目前只需关注Sharding-JDBC，它定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

        Sharding-JDBC的核心功能为****数据分片和读写分离，通过Sharding-JDBC，应用可以透明的使用jdbc访问已经分库分表、读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。
**        **

  • 适用于任何基于Java的ORM框架，如：Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。        
  • 基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
  • 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

上图展示了Sharding-Jdbc的工作方式，使用Sharding-Jdbc前需要人工对数据库进行分库分表，在应用程序中加入Sharding-Jdbc的Jar包，应用程序通过Sharding-Jdbc操作分库分表后的数据库和数据表，由于Sharding-Jdbc是对Jdbc驱动的增强，使用Sharding-Jdbc就像使用Jdbc驱动一样，在应用程序中是无需指定具体要操作的分库和分表的。

1.4.2与jdbc性能对比

  1.  能损耗测试：服务器资源充足、并发数相同，比较JDBC和Sharding-JDBC性能损耗，Sharding-JDBC相对JDBC损耗不超过7%。
  2. 性能对比测试：服务器资源使用到极限，相同的场景JDBC与Sharding-JDBC的吞吐量相当。
  3. 性能对比测试：服务器资源使用到极限，Sharding-JDBC采用分库分表后，Sharding-JDBC吞吐量较JDBC不分表有接近2倍的提升。

2.Sharding-JDBC快速入门

2.1需求说明

本章节使用Sharding-JDBC完成对订单表的水平分表，通过快速入门程序的开发，快速体验Sharding-JDBC的使用方法。 人工创建两张表，t_order_1和t_order_2，这两张表是订单表拆分后的表，通过Sharding-Jdbc向订单表插入数据， 按照一定的分片规则，主键为偶数的进入t_order_1，另一部分数据进入t_order_2，通过Sharding-Jdbc查询数据，根据 SQL语句的内容从t_order_1或t_order_2查询数据。

2.2环境搭建

2.2.1环境说明

  • 操作系统：Win10
  • 数据库：MySQL-5.7.25
  • JDK：64位jdk1.8.0_201
  • 应用框架：spring-boot-2.1.3.RELEASE，Mybatis3.5.0
  • Sharding-JDBC：sharding-jdbc-spring-boot-starter-4.0.0-RC1

2.2.2创建数据库

-- 创建订单库order_db
CREATE DATABASE `order_db` CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

-- 在order_db中创建t_order_1、t_order_2表
DROP TABLE IF EXISTS `t_order_1`; 
CREATE TABLE `t_order_1` ( 
`order_id` bigint(20) NOT NULL COMMENT '订单id', 
`price` decimal(10, 2) NOT NULL COMMENT '订单价格', 
`user_id` bigint(20) NOT NULL COMMENT '下单用户id', 
`status` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单状态', PRIMARY KEY (`order_id`) USING BTREE ) 
ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; 

DROP TABLE IF EXISTS `t_order_2`; 
CREATE TABLE `t_order_2` ( 
`order_id` bigint(20) NOT NULL COMMENT '订单id', 
`price` decimal(10, 2) NOT NULL COMMENT '订单价格', 
`user_id` bigint(20) NOT NULL COMMENT '下单用户id', 
`status` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单状态', PRIMARY KEY (`order_id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

2.2.3引入maven依赖

引入sharding-jdbc和SpringBoot整合的Jar包：

<dependency> 
    <groupId>org.apache.shardingsphere</groupId> 
    <artifactId>sharding‐jdbc‐spring‐boot‐starter</artifactId> 
    <version>4.0.0‐RC1</version> 
</dependency>

具体spring boot相关依赖及配置请参考资料中dbsharding/sharding-jdbc-simple工程，本指引只说明与Sharding-JDBC相关的内容。

2.3编写程序

2.3.1分片规则配置

分片规则配置是sharding-jdbc进行对分库分表操作的重要依据，配置内容包括：数据源、主键生成策略、分片策略等。 在application.properties中配置

server.port=56081 
spring.application.name = sharding‐jdbc‐simple‐demo
server.servlet.context‐path = /sharding‐jdbc‐simple‐demo 
spring.http.encoding.enabled = true 
spring.http.encoding.charset = UTF‐8 
spring.http.encoding.force = true 
spring.main.allow‐bean‐definition‐overriding = true
mybatis.configuration.map‐underscore‐to‐camel‐case = true 
# 以下是分片规则配置 
# 定义数据源
spring.shardingsphere.datasource.names = m1 
spring.shardingsphere.datasource.m1.type = com.alibaba.druid.pool.DruidDataSource spring.shardingsphere.datasource.m1.driver‐class‐name = com.mysql.jdbc.Driver spring.shardingsphere.datasource.m1.url = jdbc:mysql://localhost:3306/order_db?useUnicode=true 
spring.shardingsphere.datasource.m1.username = root spring.shardingsphere.datasource.m1.password = root

# 指定t_order表的数据分布情况，配置数据节点 spring.shardingsphere.sharding.tables.t_order.actual‐data‐nodes = m1.t_order_$‐>{1..2}
# 指定t_order表的主键生成策略为SNOWFLAKE 
spring.shardingsphere.sharding.tables.t_order.key‐generator.column=order_id spring.shardingsphere.sharding.tables.t_order.key‐generator.type=SNOWFLAKE

# 指定t_order表的分片策略，分片策略包括分片键和分片算法 spring.shardingsphere.sharding.tables.t_order.table‐strategy.inline.sharding‐column = order_id 
spring.shardingsphere.sharding.tables.t_order.table‐strategy.inline.algorithm‐expression = t_order_$‐>{order_id % 2 + 1}

# 打开sql输出日志 
spring.shardingsphere.props.sql.show = true 
swagger.enable = true 
logging.level.root = info 
logging.level.org.springframework.web = info 
logging.level.com.itheima.dbsharding = debug 
logging.level.druid.sql = debug
  1. 首先定义数据源m1，并对m1进行实际的参数配置。
  2. 指定t_order表的数据分布情况，他分布在m1.t_order_1，m1.t_order_2
  3. 指定t_order表的主键生成策略为SNOWFLAKE，SNOWFLAKE是一种分布式自增算法，保证id全局唯一。
  4. 定义t_order分片策略，order_id为偶数的数据落在t_order_1，为奇数的落在t_order_2，分表策略的表达式为_order_$->{order_id % 2 + 1}。

2.3.2数据操作

@Mapper
@Component
public interface OrderDao {
    /*** 新增订单 * @param price 订单价格 * @param userId 用户id * @param status 订单状态 * @return */
    @Insert("insert into t_order(price,user_id,status) value(#{price},#{userId},#{status})")
    int insertOrder(@Param("price") BigDecimal price, @Param("userId") Long userId, @Param("status") String status);

    /*** 根据id列表查询多个订单 * @param orderIds 订单id列表 * @return */
    @Select({"<script>" + 
            "select " + 
            " * " + 
            " from t_order t" + 
            " where t.order_id in " + 
            "<foreach collection='orderIds' item='id' open='(' separator=',' close=')'>" + 
            " #{id} " + 
            "</foreach>" + 
            "</script>"})
    List<Map> selectOrderbyIds(@Param("orderIds") List<Long> orderIds);
}

2.3.3测试

编写单元测试：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {ShardingJdbcSimpleDemoBootstrap.class})
public class OrderDaoTest {
    @Autowired
    private OrderDao orderDao;

    @Test
    public void testInsertOrder() {
        for (int i = 0; i < 10; i++) {
            orderDao.insertOrder(new BigDecimal((i + 1) * 5), 1L, "WAIT_PAY");
        }
    }

    @Test
    public void testSelectOrderbyIds() {
        List<Long> ids = new ArrayList<>();
        ids.add(373771636085620736L);
        ids.add(373771635804602369L);
        List<Map> maps = orderDao.selectOrderbyIds(ids);
        System.out.println(maps);
    }
}

执行testInsertOrder，通过日志可以发现order_id为奇数的被插入到t_order_2表，为偶数的被插入到t_order_1表，达到预期目标。

执行testSelectOrderbyIds，通过日志可以发现，根据传入order_id的奇偶不同，sharding-jdbc分别去不同的表检索数据，达到预期目标。

2.4流程分析

通过日志分析，Sharding-JDBC在拿到用户要执行的sql之后干了哪些事儿：
（1）解析sql，获取片键值，在本例中是order_id；

（2）Sharding-JDBC通过规则配置t_order_$->{order_id % 2 + 1}，知道了当order_id为偶数时，应该往 t_order_1表插数据，为奇数时，往t_order_2插数据。
（3）于是Sharding-JDBC根据order_id的值改写sql语句，改写后的SQL语句是真实所要执行的SQL语句。

（4）执行改写后的真实sql语句
（5）将所有真正执行sq

2.5其他集成方式

Sharding-JDBC不仅可以与spring boot良好集成，它还支持其他配置方式，共支持以下四种集成方式。

Spring Boot Yaml****配置定义application.yml，内容如下。

server: 
    port: 56081 
    servlet: 
        context‐path: /sharding‐jdbc‐simple‐demo
spring: 
    application: 
        name: sharding‐jdbc‐simple‐demo 
    http: 
        encoding: 
            enabled: true 
            charset: utf‐8 
            force: true
    main: 
        allow‐bean‐definition‐overriding: true 
    shardingsphere: 
        datasource: 
            names: m1
            m1:
                type: com.alibaba.druid.pool.DruidDataSource 
                driverClassName: com.mysql.jdbc.Driver 
                url: jdbc:mysql://localhost:3306/order_db?useUnicode=true 
                username: root 
                password: mysql
        sharding: 
            tables: 
                t_order: 
                    actualDataNodes: m1.t_order_$‐>{1..2} 
                    tableStrategy: 
                        inline: 
                            shardingColumn: order_id 
                            algorithmExpression: t_order_$‐>{order_id % 2 + 1}            
                    keyGenerator: 
                        type: SNOWFLAKE 
                        column: order_id
       props: 
         sql:
            show: true
mybatis: 
    configuration: 
        map‐underscore‐to‐camel‐case: true
swagger: 
    enable: true
logging: 
    level: 
        root: info
        org.springframework.web: info 
        com.itheima.dbsharding: debug 
        druid.sql: debug

Java****配置，添加配置类。

public class ShardingJdbcConfig {
    // 定义数据源
    Map<String, DataSource> createDataSourceMap() {
        DruidDataSource dataSource1 = new DruidDataSource();
        dataSource1.setDriverClassName("com.mysql.jdbc.Driver");
        dataSource1.setUrl("jdbc:mysql://localhost:3306/order_db?useUnicode=true");
        dataSource1.setUsername("root");
        dataSource1.setPassword("root");
        Map<String, DataSource> result = new HashMap<>();
        result.put("m1", dataSource1);
        return result;
    }

    // 定义主键生成策略
    private static KeyGeneratorConfiguration getKeyGeneratorConfiguration() {
        KeyGeneratorConfiguration result = new KeyGeneratorConfiguration("SNOWFLAKE", "order_id");
        return result;
    }

    // 定义t_order表的分片策略
    TableRuleConfiguration getOrderTableRuleConfiguration() {
        TableRuleConfiguration result = new TableRuleConfiguration("t_order", "m1.t_order_$‐> {1..2}");
        result.setTableShardingStrategyConfig(new InlineShardingStrategyConfiguration("order_id", "t_order_$‐>{order_id % 2 + 1}"));
        result.setKeyGeneratorConfig(getKeyGeneratorConfiguration());
        return result;
    }

    // 定义sharding‐Jdbc数据源
    @Bean
    DataSource getShardingDataSource() throws SQLException {
        ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();
        shardingRuleConfig.getTableRuleConfigs().add(getOrderTableRuleConfiguration());
        //spring.shardingsphere.props.sql.show = true
        Properties properties = new Properties();
        properties.put("sql.show", "true");
        return ShardingDataSourceFactory.createDataSource(createDataSourceMap(), shardingRuleConfig, properties);
    }
}

3.Sharding-JDBC执行原理

3.1基本概念

在了解Sharding-JDBC的执行原理前，需要了解以下概念：
**        逻辑表**：水平拆分的数据表的总称。例：订单数据表根据主键尾数拆分为10张表，分别是t_order_0、t_order_1到 t_order_9 ，他们的逻辑表名为t_order。

        

**        真实表**：在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到t_order_9。
        

**        数据节点**：数据分片的最小物理单元。由数据源名称和数据表组成，例： ds_0.t_order_0。
        

**        绑定表**：指分片规则一致的主表和子表。例如： t_order表和t_order_item表，均按照order_id分片,绑定表之间的分区键完全相同，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果SQL为

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在不配置绑定表关系时，假设分片键 order_id将数值10路由至第0片，将数值11路由至第1片，那么路由后的SQL应该为4条，它们呈现为笛卡尔积：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

        在配置绑定表关系后，路由的SQL应该为2条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

**        广播表**：指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。
        

**       分片键**：用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，Sharding- Jdbc也支持根据多个字段进行分片。
        **分片算法：**通过分片算法将数据分片，支持通过=、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。包括：精确分片算法 、范围分片算法 ，复合分片算法 等。例如：where order_id = ?将采用精确分片算法，where order_id in (?,?,?)将采用精确分片算法，where order_id BETWEEN ? and ?将采用范围分片算法，复合分片算法用于分片键有多个复杂情况。

        **分片策略：**包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键+分片算法，也就是分片策略。内置的分片策略大致可分为尾数取模、哈希、范围、标签、时间等。由用户方配置的分片策略则更加灵活，常用的使用行表达式配置分片策略，它采用Groovy表达式表示，如:t_user_$->{u_id % 8}表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。
         **自增主键生成策略：**通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。

3.2SQL解析

当Sharding-JDBC接受到一条SQL语句时，会陆续执行SQL解析=>查询优化=> SQL路由=> SQL改写=> SQL执行=> 结果归并 ，最终返回执行结果。

3.3SQL路由

3.4SQL改写

3.5SQL执行

3.6结果归并

3.7总结

版权说明 : 本文为转载文章, 版权归原作者所有 版权申明

原文链接 : https://yangchuntao.blog.csdn.net/article/details/120712218

内容来源于网络，如有侵权，请联系作者删除！

Java

相关文章

    查看更多

    热门标签

    更多
    JavaquerypythonNode开发语言requestUtil数据库Table后端算法LoggerMessageElementParser

    最新文章

    更多
    • 蜀ICP备2022004421号-2 NULL123 https://www.null123.com © All rights reserved
    • 本站内容来源互联网,如果侵犯您的权益请联系我们删除, 联系方式：448109455@qq.com