分库分表方案深入讲解，学不会你捶我

一、背景介绍

移动互联网时代，随着软件用户量的不断增长，由此产生的数据量也在飞速增长，比如，用户表、订单表、聊天消息表等。据统计，MySQL单表可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW量级是最佳状态，因为这时它的BTREE索引树高在3~5之间。

既然一张表无法搞定，那么就想办法将数据存放到多个地方，目前比较普遍的方案有3个：

1. 分区

• 要求数据不是海量（分区数有限，存储能力就有限）

• 业务并发能力要求不高

• 分库分表

• • 互联网行业处理海量数据的通用方法

  • 发展几十年的RDBMS（关系型数据库）具有生态完善、绝对稳定、事务特性的优点，只要有软件的地方，它都是核心存储的首选

• NoSQL/NewSQL

• • NoSQL/NewSQL宣传的无论多厉害，就现在各大公司对它的定位，都是RDBMS的补充，而不是取而代之

  本文就分库分表的一些核心流程展开介绍：

  

  二、是单库分表，还是分库分表

  • 单库分表适用场景：

  1. 单表数据量太大，查询时需要扫描的行数太多，SQL执行效率低下

  2. CPU出现瓶颈

• 分库分表适用场景：

• 1. 磁盘读IO达到了瓶颈：热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，导致查询速度低下

  2. 请求的数据太多、网络带宽不够

  3. 数据库连接数超过了最大限定值

  分库分表的复杂度要高于单库分表，如果数据量不是特别大，且QPS也不是特别高，首选单库分表，待某些指标有接近阈值的迹象时，再考虑分库分表。

  分库分表相对单库分表来说，复杂的地方有：

  • 需要约定多个分片数据源

  • 需要定义多个分片数据源的事务管理器

  • 数据一致性的处理方案（强一致 or 最终一致）

  • 数据迁移、后续扩容

  • ...

  三、分布式数据库中间件选型

  本文主要针对时下比较流行的两款数据库中间件产品做下介绍：

  主要指标	Sharding-JDBC	MyCat
  所属	Apache	基于阿里 Cobar 二次开发，社区维护
  活跃度	高	高
  ORM支持	任意	任意
  基于客户端还是服务端	客户端	服务端
  分库	支持	支持
  分表	支持	不支持单库分表
  事务	自带弱XA、最大努力送达型柔性事务	自带弱XA
  监控	无，可通过其它方式支持	自带
  读写分离	支持	支持
  限制	部分 JDBC 方法不支持、SQL语句限制	部分 JDBC 方法不支持、SQL语句限制
  数据库连接池	任意	任意
  MySQL交互协议	JDBC Driver	前后端均用 NIO
  开发	开发成本高，代码入侵大	开发成本小，代码入侵小
  运维	维护成本低	维护成本高
  配置难度	一般	复杂

  Sharding-JDBC

  架构图：

  

  简单介绍：

  • Sharding-JDBC是一款轻量级的框架，以工程依赖JAR的形式提供功能，无需额外部署和依赖，可以理解为增强版的JDBC驱动

  • 对于运维同事来说，只需要协助一些简单的配置及后续的扩容工作，无需关注底层代码与分片策略规则，相对MyCat，这是 Sharding-JDBC的优势，减少了部署成本以及运维同事的学习成本

  MyCat

  架构图

  

  简单介绍：

  • MyCat并不是业务系统代码里面的配置，而是独立运行的中间件，所有配置都会交给运维同事执行

  • 对于运维同事来说，它是在数据库Server前增加的一层代理，MyCat本身不存数据，数据存储在后端的数据库上，因此，数据可靠性以及事务等都是通过数据库保证的

  • MyCat down 掉的时候，系统不能对数据库进行操作，会对所有用户产生影响

  • MyCat比较适合大数据工作

  通过以上分析，可见Sharding-JDBC相对MyCat来说，更轻量，首选肯定是Sharding-JDBC，只要代码层面做好防腐层（依赖倒置）的设计，就算以后数据量级达到了百亿、千亿，也可以更加灵活方便的替换其它中间件产品，甚至 NewSQL。

  四、分布式ID的生成方式

  实现方式

  • 完全依赖数据源的方式：ID的生成规则，读取控制完全由数据源控制，常见的如数据库自增长ID、优雅的Flickr方案、基于Redis的原子操作incr/incrBy产生顺序号、Mongodb的ObjectId、美团(Leaf)的号段模式...

  • 半依赖数据源的方式：