Sharding-Jdbc分库分表常见问题解决方案讲解

一、掌握Sharding-Jdbc分库分表后已经解决的三大问题

• 问题一：执行的SQL排序、翻页、函数计算问题
  • 分库后，数据分布再不同的节点上， 跨节点多库进行查询时，会出现limit分页、order by排序等问题
  • 而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序（也会带来更多的CPU/IO资源损耗）
  • 解决方式：
    • 业务上要设计合理，利用好PartitionKey，查询的数据分布同个数据节点上，避免 跨节点多库进行查询时
    • sharding-jdbc在结果合并层自动帮我们解决很多问题（流式归并和内存归并）

     

• 问题二：数据库全局主键重复问题
  • 常规表的id是使用自增id进行实现，分库分表后，由于表中数据同时存在不同数据库中，如果用自增id，则会出现冲突问题
  • 解决方式：
    • UUID
    • 自研发号器 redis
    • 雪花算法

     

• 问题三：分库分表技术选型问题
  • 市场分库分表中间件相对较多，框架各有各的优势与短板，应该如何选择
  • 解决方式
    • 开源产品：主要是Mycat和ShardingJdbc区别，也是被面试官问比较多的
      • 两者设计理念相同，主流程都是SQL解析-->SQL路由-->SQL改写-->结果归并
      • sharding-jdbc（推荐）
        • 基于jdbc驱动，不用额外的proxy，在本地应用层重写Jdbc原生的方法，实现数据库分片形式
        • 是基于 JDBC 接口的扩展，是以 jar 包的形式提供轻量级服务的，性能高
        • 代码有侵入性
      • Mycat
        • 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成一个 MySQL 数据库
        • 客户端所有的jdbc请求都必须要先交给MyCat，再有MyCat转发到具体的真实服务器
        • 缺点是效率偏低，中间包装了一层
        • 代码无侵入性

二、Sharding-Jdbc 分库分表-跨节点数据库Join关联和多维度查询

• 问题：跨节点数据库Join关联查询 和 多维度查询
  • 数据库切分前，多表关联查询，可以通过sql join进行实现
  • 分库分表后，数据可能分布在不同的节点上，sql join带来的问题就比较麻烦
  • 不同维度查看数据，利用的partitionKey是不一样的
  • 解决方案
    • 冗余字段
    • 广播表
    • NOSQL汇总
  • 案例一
    • 订单需要用户的基本信息，但是分布在不同库上
    • 进行字段冗余，订单表冗余用户昵称、头像
  • 案例二
    • 订单表 的partionKey是user_id，用户查看自己的订单列表方便
    • 但商家查看自己店铺的订单列表就麻烦，分布在不同数据节点
      • 订单冗余存储在es上一份
      • 业务架构流程

 

三、Sharding-Jdbc容量规划-分库分表后二次扩容问题

• 问题：容量规划,分库分表后二次扩容问题
  • 业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容，数据迁移问题
  • 取决是哪种分库分表规则
    • Range范围
      • 时间：不用考虑扩容迁移
      • 区域：调整分片粒度，需要全量迁移
    • Hash取模
      • 解决方式
        • 业务最多的是hash取模分片，因扩分库分表涉及到rehash过程
        • 分片数量建议可以成倍扩容策略，只需要【迁移部分数据】即可
          • 旧节点的数据，有一半要迁移至一个新增节点中

      

       

      • 更多解决方式
        • 利用一致性Hash思想，增加虚拟节点，减少迁移数据量
        • 专门的数据库表，记录数据存储位置，进行路由
        • ...

四、Sharding-Jdbc 分库分表-二次扩容实施方案讲解

• 方式一
  • 利用数据库主从同步

  

  • 新增两个数据库 A2、A3 作为从库，设置主从同步关系为：A0=>A2、A1=>A3,
  • 开启主从数据同步，早期数据手工同步过去
  • 发布新程序，某个时间点开始，利用MQ存储CUD操作
  • 关闭数据库实例的主从同步关系
  • 校验数据，消费原先MQ存储CUD操作,配置新分片规则和生效
  • 数据校验和修复
    • 依赖gmt_modified字段，所以常规数据表都需要加这个字段
    • 由数据库自己维护值，根据业务场景，进行修复对应的数据
    • 校验步骤
      • 开始迁移时间假如是2022-01-01 00:00:00
      • 查找 gmt_modified数据校验修复大于开始时间点，就是修改过的数据
  • 各个节点的冗余数据进行删除
  • 缺点
    • 同步的很多数据到最后都需要被删除
    • 一定要提前做，越晚做成本越高，因为扩容期间需要存储的数据更多
    • 基本都离不开代码侵入，加锁等操作
  • 优点
    • 利用mysql自带的主从同步能力
    • 方案简单，代码量相对少

   

   

  • 方式二
    • 小滴课堂-老王的最佳选择，对外发布公告，停机迁移
    • 严格一致性要求：比如证券、银行部分数据等
    • 优点：最方便、且安全
    • 缺点
      • 会造成服务不可用，影响业务
      • 根据停机的时间段，数据校验人员有压力