海量数据分库分表方案（二）技术选型

2019-09-28  本文已影响0人  地藏Kelvin

上一章已经讲述分库分表算法选型，本章主要讲述分库分表技术选型

文中关联上一章，若下文出现提及其时，可以点击 分库分表算法方案与技术选型（一）

主要讲述

常见框架

除了原生JDBC，网上常见分库分表框架有：
当当网 sharding-jdbc
alibaba.cobar (是阿里巴巴（B2B）部门开发)
MyCAT（基于阿里开源的Cobar产品而研发）
蚂蚁金服 ZDAL （开源）
蘑菇街 TSharding

当然除了这些，还有很多各自公司提出的框架，但是根据用户量较高的为以上几种。
其中自从出现基于cobar的MyCAT,zdal，也很少人用cobar了。ZDAL虽然也是开源，但是很少文章和使用反馈，不支持MongoDb，交流活跃度也比较低。

所以本次文章来比较一下活跃度较高的sharding-jdbc和MyCAT。

扩展阅读：当当网做的不错的，除了sharding-jdbc，还有elastic-job用于定时任务分片

对比概览

主要指标 Sharding-jdbc Mycat zdal
ORM支持 任意 任意 任意
事务 自带弱XA、最大努力送达型柔性事务BASE 自带弱XA 自带弱XA、最大努力送达型柔性事务BASE
分库 支持 支持 支持
分库 支持 不支持单库分表 支持
开发 开发成本高，代码入侵大 开发成本小，代码入侵小 开发成本不算高配置明确
所属公司 当当网 基于阿里Cobar二次开发，社区维护 蚂蚁金服
数据库支持 任意 Oracle、 SQL Server、 Mysql、DB2、mongodb 不支持mongodb
活跃度 也有不少的企业在最近几年新项目使用 社区活跃度很高，一些公司已在使用 活跃度低
监控 无 有
读写分离 支持 支持
资料 资料少、github、官网、网上讨论贴 资料多，github、官网、Q群、书籍 少
运维 维护成本低 维护成本高 维护成本低
限制 部分JDBC方法不支持、SQL语句限制 SQL语句限制
连接池 druid版本 无要求 无要求
配置难度 一般 复杂 比较简单，读写分离、分开分表规则设置量少

关键指标对比

1.开发与运维成本

sharding-jdbc

MyCat

  1. 而MyCat并不是业务系统代码里面的配置，而是独立运行的中间件，所以配置都会交给DBA执行。
  2. 对于DBA来说，他是一个在mysql Server前，增加一层代理，mycat本身不存数据，数据是在后端的MySQL上存储的，因此数据可靠性以及事务等都是MySQL保证的。
  3. 为了减少迁移数据的风险，在 上一章推荐的增量迁移算法方案（推荐大家阅读）讲述如何分片达到降低风险。
    若用MyCat，DBA需要配置多次的增量分片规则，每配置一次则要重启一次，才能达到一轮的数据迁移。实际上MyCat down掉的时系统都不能对数据库查询，实际依然对所有用户有影响。
  4. 然而sharding-jdbc都在代码实现路由规则，则可以减少DBA操作次数和系统重启次数，进而减少影响用户数。

推荐阅读第一章的第五节才比较好理解上述3~4点 分库分表算法方案与技术选型（一）

  1. proxy整合大数据思路，将 OLTP 和 OLAP 分离处理，可能会对大数据处理的系统比较适合，毕竟数据工作不一定有java后端系统。

该点总结：sharding-jdbc增量分片和增量迁移数据效果更佳，mycat比较适合大数据工作

备注：
sharding-jdbc增强了JDBC驱动部分功能，但同时也限制部分原生JDBC接口的使用。具体限制参考：
限制情况：http://dangdangdotcom.github.io/sharding-jdbc/01-start/limitations/ 这个文档现在好像访问不了
附：
官网文档
官网源码

MyCat配置样例
MyCat配置样例2

2.分库分表能力

3.事务

首先说说XA， XA 多阶段提交的方式，虽然对分布式数据的完整性有比较好的保障，但会极大的降影响应用性能。

备注:
还有一种柔性事务类型是 TCC，即 Try Confirm Cancel。可以通过事务管理器控制事务的提交或回滚，更加接近原生事务，但仍然是最终一致性。其缺点是需要业务代码自行实现 Try Confirm Cancel 的接口，对现有业务带来一定冲击。Sharding-JDBC 未对 TCC 的支持。

4.监控

为什么要监控，因为上述事务的弱XA、最大努力送达型，其实还是有概率失败。

5.语句限制

6.比较蚂蚁金服的zdal

相对zdal来说，sharding-jdbc的配置量差不多，但是sharding-jdbc提供了java、springboot、yml、spring命名空间方式，而且有官方网站和gitee网站维护。相对zdal用户更加活跃。

Sharding-jdbc分库分表整合mybatis-plus 开发样例

代码样例具体描述，下述关键的开发点。
具体源码请到我的gitee地址sharding-jdbc-example。

sharding-jdbc分片的开发主要几个关键点：

  1. 在xml中配置基础数据源、分库分表的策略，其中DbShardingAlgorithm，TbShardingAlgorithm需要在java代码里面实现。
    sharding-jdbc分片的开发主要几个关键点：
  2. 引入关键依赖 2019.10最新版4.0.0-RC2
         <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>sharding-jdbc-spring-namespace</artifactId>
            <version>4.0.0-RC2</version>
        </dependency>
  1. 在xml中配置基础数据源、分库分表的策略，其中DbShardingAlgorithm，TbShardingAlgorithm需要在java代码里面实现。
<--分库的规则对象类->
    <bean id="preciseModuloDatabaseShardingAlgorithm" class="com.dizang.sharding.config.algorithm.DbShardingAlgorithm" />
    <--分表规则对象类->
    <bean id="preciseModuloTableShardingAlgorithm" class="com.dizang.sharding.config.algorithm.TbShardingAlgorithm" />
    <--分库根据的key->
    <sharding:standard-strategy id="databaseStrategy" sharding-column="user_id" precise-algorithm-ref="preciseModuloDatabaseShardingAlgorithm" />
    <--分库根据的key->
    <sharding:standard-strategy id="tableShardingStrategy" sharding-column="user_id" precise-algorithm-ref="preciseModuloTableShardingAlgorithm" />
    
    <sharding:key-generator id="orderKeyGenerator" type="SNOWFLAKE" column="id" />
    
    <sharding:data-source id="shardingDataSource">
    <--分表数据源->
        <sharding:sharding-rule data-source-names="ds0, ds1">
            <sharding:table-rules>
            <--逻辑表名->
                <sharding:table-rule logic-table="t_user" 
                actual-data-nodes="ds$->{0..1}.t_user_$->{0..2}" 
                <--分库分表逻辑bean->
                database-strategy-ref="databaseStrategy" 
                table-strategy-ref="tableShardingStrategy" 
                key-generator-ref="orderKeyGenerator" />
            </sharding:table-rules>
            <--配置能适用规则的表->
            <sharding:binding-table-rules>
                <sharding:binding-table-rule logic-tables="t_user" />
            </sharding:binding-table-rules>
            <--配置不需要分库分表的表->
            <sharding:broadcast-table-rules>
                <sharding:broadcast-table-rule table="t_order" />
            </sharding:broadcast-table-rules>
        </sharding:sharding-rule>
    </sharding:data-source>

<--sqlSessionFactory配置shardingDataSource数据源->
    <bean id="sqlSessionFactory"
    class="com.baomidou.mybatisplus.extension.spring.MybatisSqlSessionFactoryBean"> 
        <property name="dataSource" ref="shardingDataSource"/>
        <property name="mapperLocations" value="classpath*:mapper/*.xml"/>
    </bean>
  1. java代码编写分库策略
    需要继承SingleKeyDatabaseShardingAlgorithm分开规则类，重写equal等于、大于、小于时的路由规则
public class DbShardingAlgorithm implements PreciseShardingAlgorithm<Long>{  

    @Override
    public String doSharding(Collection<String> databaseNames, PreciseShardingValue<Long> shardingValue) {
        for (String each : databaseNames) {
            if (each.endsWith(shardingValue.getValue() % 2 + "")) {
                return each;
            }
        }
        return null;
    }  

}
  1. java代码编写分表策略
    需要继承SingleKeyTableShardingAlgorithm分开规则类，重写equal等于、大于、小于时的路由规则
public class TbShardingAlgorithm implements PreciseShardingAlgorithm<Long>{  

    @Override
    public String doSharding(Collection<String> tableNames, PreciseShardingValue<Long> shardingValue) {
        for (String each : tableNames) {
            if (each.endsWith(shardingValue.getValue() % 2 + "")) {
                return each;
            }
        }
//        return shardingValue.getLogicTableName()+(shardingValue.getValue() % 2);
        throw new UnsupportedOperationException();
    }  

}

zdal具体代码实现推荐阅读

Zdal分库分表介绍、超详细一步一步搭建简单的zdal框架

欢迎关注

我的公众号 ：地藏思维

我的Gitee： 地藏Kelvin https://gitee.com/dizang-kelvin

推荐阅读sharding-jdbc源码：

Sharding-JDBC 源码解析合集

Sharding-JDBC 源码分析 —— SQL 改写

原生jdbc读写分离

上一篇 下一篇

猜你喜欢

热点阅读