一 简介:分库分表的理解

二 具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展

              2 本文仅从中间层观点进行分析

三 现有方案

  方案1 sharding家族

• Sharding-JDBC是一款轻量级的Java框架，在JDBC层提供上述核心功能，使用方式与正常的JDBC方式如出一辙，面向Java开发的用户。

• Sharding-Proxy是一款实现了MySQL二进制协议的服务器端版本，大家可以把它当成升级版的MySQL数据库使用。独立部署后，即可按照正常MySQL操作方式来使用上述所有的核心功能。

• Sharding-Sidecar从Service Mesh的理念中应用而生，面向于云原生架构

  设计 在程序端利用sharding家族进行设计控制,根据计算出的路由指定数据库节点.

  特点 sharding优势

        1 程序端进行控制,非常方便.利用代码计算分片字段,控制分片规则.不会产生性能损耗

        2 程序能够封装面对不同种类数据库

         sharding问题

         1 不支持分布式事务,需要利用路由进行事务操作

         2 不支持分布式事务,全局DDL需要到每个分片进行执行

         3 不支持动态扩容

         4 不具有通用性,因为是根据业务进行设计的

    过程 通过对片键的换算绝对分片节点,再通过片键的换算定位分表,达到分片分表目的

  方案 2 中间件家族

  设计 采用开源界的开源中间件进行设计控制,路由规则和分片都配置在中间件,然后指定后端机器

  特点 1 开源中间件分为两种

             一种是支持分布式事务,比如cetus mycat

             一种是不支持分布式事务,比如kingshard

          2 开源中间件的优势

            1 中间件具有通用性,定义好的分片方法和路由规则,可以应用到多种业务场景

            2 中间件大多拥有读写分离特性,可以直接应用

          3 开源中间件可能存在的问题

            1 中间件本身hang住,导致业务不可用

            2 中间件本身发生崩溃或者OOM占用很高,导致业务不可用

            3 中间件本身的性能损耗问题,是否可以接受

            4 中间件如果上线,程序还是得做一定程度的浅改造

            5 中间件本身也不支持动态扩容

            6 中间件是否还在开源界维护

            7 中间件维护和备份数据等问题

 四 存在的普遍问题

      1 全局事务控制的问题,即便是支持全局事务控制的中间件,也极度依赖mysql自身的XA事务.但是mysql xa 到了5.7后续版本才逐渐完善

      2 全局事务DDL的一致性和代价问题,这也是一个针对多分片非常头疼的问题,不论对于哪种场景下

      3 一旦采用分片,后续的查询限制问题,需要改造业务

      4 分片集群的扩容问题,这是一个非常麻烦的事情,可以摆放在分片方案的首位

      5 分片集群的备份数据一致性问题

五 分片集群的普通扩容方案思路

     准备条件

       1 完全一倍的硬件替换环境

       2 需要在分片时准备足够多的桶

     方案1

       1 利用备份工具备份各个分片的数据,并记录下此时的主库binlog相关信息

       2 利用备份恢复到新建立的集群中,一式两份.

       3 利用修改好的新算法程序并行进行每个节点多余数据的删除

       4 利用主库binlog相关信息搭配canal进行每个节点的同步

       5 停止业务,保证新旧集群的数据一致

       6 流量进行切换

       7 旧集群进行下线处理

    方案2

     1 准备好相应的新程序,硬件环境,一个超级账户

     2 新程序接入线上从库,通过超级账户执行两件事

       1 停止复制进程

       2 记录此时的同步binlog信息

     3 新程序开始进行操作

         1 读取从库数据,以新的算法进行录入新集群

         2 对录入的数据进行校验,校验成功后对从库进行删除操作

     4 当执行完时,从库就没有数据了,数据都在新集群了

     5 利用从库同步的binlog信息进行canal消费

      6 当canal消费追上主库后停止业务

      7 流量进行切换

      8 就集群进行下线处理

      9 注意:确保mysql主库必须保留足够时间的binlog文件

  六 分片集群主键的规划

      目的 保证集群本身各个节点的主键不唯一

      分类

       1 uuid 最原始(不建议用这个),保证唯一

       2 业务组合数字串(time+产品ID+用户ID)类似标记唯一,而且还能进行利用

      3 通过雪花算法生成(需要时钟校验,否则可能产生冲突)

      我们强烈推荐第二种方案,具有业务意义的主键才是我们需要的,我们本身也采用第二种

 七 分片集群的查询

    1 实时跨分片的业务尽量改造或者避免,效率很低

    2 非实时查询业务我强烈建议采用canal+es方式,es汇总集群所有数据进行后台查询

 八 总结

    几个关键点

   1 在哪个阶段进行分片,是否具有通用性

   2 是否需要支持分布式事务

   3 集群的分片扩容和查询问题

   4 集群的全局事务ID规划

 九 补充点

   找到适合业务具体的方案,稳定适合才是重要的,具体问题具体分析.本篇文章只是个人观点.