分库分表之sharding-jdbc

分库分表之sharding-jdbc

背景：

随着mysql越来越成熟以及去IOE的大势下，mysql被互联网公司运用的炉火纯青的同时，也被带进金融行业。但金融行业有其特殊属性，对数据的要求非常高，而相对轻巧mysql数据库往往需要辅助工具来解决某些严苛的使用场景。而因为mysql的轻巧等因素，导致其单机比较容易出现性能瓶颈，而成熟的oralce单机性能强悍。但是对比成熟且昂贵的oracle来说，开源免费的特性配合成熟的生态使得越来越被企业选用，但相应的运维能力要求也水涨船高。

以金融业的某银行为例，其新建设的网络信用贷款系统采用分布式架构，数据库存储采用mysql。系统架构之初将应用按照业务粒度拆分，同时为每个应用设计一个数据库，专库专用，但所有的库都集中在一台机器上。新系统刚上线业务量不大，而迁移过来的数据量也不大，单机跑也问题不大。但随着后续接入的产品越来越多，业务上来后，存储的数据达到千万级别后，单机瓶颈会突显，cpu占用高，io读写速度慢，数据占用磁盘巨大等噩需解决的棘手问题。此时可进行多种方案将单机性能瓶颈上移，比如拆库，采用中间件分库分表等。但无论采用哪种方案，风险都在，效果也不相同。

有没有一种相对不需要太高运维能力的技术，达到分库分表呢？当当网开源的sharding-jdbc就很适合，只需要引入一个jar包，加上配置即可。对开发透明，也无需多加中间件机器，大大减少运维难度，达到单库变多库，单表变多表，从而达到提升系统性能等优势。

分库分表：

分库：分为水平分库和垂直分库。水平分库简单理解就是一个库复制几个一摸一样的库，垂直分库简单理解就是将原本一个库按业务或者其它维度拆分成多个库。

分表：分为水平分表和垂直分表。简单理解跟分库差不多，水平分表即复制几个一摸一样的表，垂直分表就是将原本一个表的字段以业务或者其它规则拆分成几个表。

分库分表带来如下问题：

事务一致性：

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

跨关联节点查询：

在没分库前，查询关联表，直接关联就行。分库后，关联表可能不在一个库，甚至不在一台机器上，以往查询一次的情况，可能需要查询两次。

跨界点分页排序：