之前有不少刚入坑 Java 的粉丝留言，想零碎的学习一下分库分表相干技术，可我始终没下定决心搞，眼下赶上公司我的项目在应用 sharding-jdbc 对现有 MySQL 架构做分库分表的革新，所以借此机会出一系分库分表落地实际的文章，也算是本人对架构学习的一个总结。
我在网上陆陆续续的也看了一些有对于分库分表的文章，可发现网上同质化的材料有点多，而且知识点又都比拟系统，还没有具体的实战案例。为了更深刻的学习下，我在某些平台买了点付费课程，看了几节课发现有点教训的人看还能够，但对于新手入门来说，其实学习难度还是蛮大的。
为了让老手也能看得懂，有些知识点我可能会用更多的篇幅加以形容，心愿大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源进来，能帮一个算一个吧！如果发现文中有哪些谬误或不谨严之处，欢送大家交换斧正。
具体实际分库分表之前在啰嗦几句，回头温习下分库分表的根底概念。
什么是分库分表
其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于咱们习惯性的将它们合在一起叫做分库分表。
分库分表是为了解决因为库、表数据量过大，而导致数据库性能继续降落的问题。依照肯定的规定，将本来数据量大的数据库拆分成多个独自的数据库，将本来数据量大的表拆分成若干个数据表，使得繁多的库、表性能达到最优的成果（响应速度快），以此晋升整体数据库性能。
如何分库分表
分库分表的核心理念就是对数据进行切分（Sharding），以及切分后如何对数据的疾速定位与查问后果整合。而分库与分表都能够从：垂直 （纵向）和 程度（横向）两种纬度进行切分。
下边咱们就以订单相干的业务举例，看看如何做库、表的 垂直 和 程度 切分。
垂直切分
垂直切分有 垂直 分库 和 垂直 分表。
1、垂直分库
垂直分库相对来说是比拟好了解的，核心理念就四个字：专库专用。
按业务类型对表进行分类，像订单、领取、优惠券、积分等相应的表放在对应的数据库中。开发者不能够跨库直连别的业务数据库，想要其余业务数据，对应业务方能够提供 API 接口，这就是微服务的初始状态。
垂直分库很大水平上取决于业务的划分，但有时候业务间的划分并不是那么清晰，比方：订单数据的拆分要思考到与其余业务间的关联关系，并不是说间接把订单相干的表放在一个库里这么简略。
在肯定水平上，垂直分库仿佛晋升了一些数据库性能，可实际上并没有解决因为单表数据量过大导致的性能问题，所以就须要配合程度切分形式来解决。
2、垂直分表
垂直分表 是基于数据表的列（字段）为根据切分的，是一种大表拆小表的模式。
例如：一张 order 订单表，将订单金额、订单编号等拜访频繁的字段，独自拆成一张表，把 blob 类型这样的大字段或拜访不频繁的字段，拆分进去创立一个独自的扩大表 work_extend，这样每张表只存储原表的一部分字段，再将拆分进去的表扩散到不同的库中。
咱们晓得数据库是以行为单位将数据加载到内存中，这样拆分当前外围表大多是拜访频率较高的字段，而且字段长度也都较短，因此能够加载更多数据到内存中，来减少查问的命中率，缩小磁盘 IO，以此来晋升数据库性能。
垂直切分的长处：
- 业务间数据解耦，不同业务的数据进行独立的保护、监控、扩大。
- 在高并发场景下，肯定水平上缓解了数据库的压力。
垂直切分的毛病：
- 晋升了开发的复杂度，因为业务的隔离性，很多表无奈间接拜访，必须通过接口方式聚合数据。
- 分布式事务管理难度减少。
- 数据库还是存在单表数据量过大的问题，并未基本上解决，须要配合程度切分。
-
- *
程度切分
前边说了垂直切分还是会存在单库、表数据量过大的问题，当咱们的利用曾经无奈在细粒度的垂直切分时，
仍旧存在单库读写、存储性能瓶颈，这时就要配合程度切分一起了，程度切分能大幅晋升数据库性能。
1、程度分库
程度分库是把同一个表按肯定规定拆分到不同的数据库中，每个库能够位于不同的服务器上，以此实现程度扩大，是一种常见的晋升数据库性能的形式。
这种计划往往能解决单库存储量及性能瓶颈问题，但因为同一个表被调配在不同的数据库中，数据的拜访须要额定的路由工作，因而零碎的复杂度也被晋升了。
例如下图，订单 DB_1、订单 DB_1、订单 DB_3 三个数据库内有完全相同的表 order，咱们在拜访某一笔订单时能够通过对订单的订单编号取模的形式 订单编号 mod 3（数据库实例数），指定该订单应该在哪个数据库中操作。
2、程度分表
程度分表是在 同一个数据库内，把一张大数据量的表按肯定规定，切分成多个构造完全相同表，而每个表只存原表的一部分数据。
例如：一张 order 订单表有 900 万数据，通过程度拆分进去三个表，order_1、order_2、order_3，每张表存有数据 300 万，以此类推。
程度分表只管拆分了表，但子表都还是在同一个数据库实例中，只是解决了繁多表数据量过大的问题，并没有将拆分后的表扩散到不同的机器上，还在竞争同一个物理机的 CPU、内存、网络 IO 等。要想进一步晋升性能，就须要将拆分后的表扩散到不同的数据库中，达到分布式的成果。
程度切分的长处：
- 解决高并发时单库数据量过大的问题，晋升零碎稳定性和负载能力。
- 业务零碎革新的工作量不是很大。
程度切分的毛病：
- 跨分片的事务一致性难以保障。
- 跨库的 join 关联查问性能较差。
- 扩容的难度和保护量较大，（拆分成几千张子表想想都恐怖）。
-
- *
肯定规定是什么
咱们上边提到过很屡次 肯定规定，这个规定其实是一种路由算法，就是决定一条数据具体应该存在哪个数据库的哪张表里。
常见的有 取模算法 和 范畴限定算法
1、取模算法
按字段取模（对 hash 后果取余数 (hash() mod N)，N 为数据库实例数或子表数量）是最为常见的一种切分形式。
还拿 order 订单表举例，先对数据库从 0 到 N- 1 进行编号，对 order 订单表中 work_no 订单编号字段进行取模，失去余数 i，i=0存第一个库，i=1存第二个库，i=2存第三个库 …. 以此类推。
这样同一笔订单的数据都会存在同一个库、表里，查问时用雷同的规定，用 work_no 订单编号作为查问条件，就能疾速的定位到数据。
长处：
- 数据分片绝对比拟平均，不易呈现申请都打到一个库上的状况。
毛病：
- 这种算法存在一些问题，当某一台机器宕机，本应该落在该数据库的申请就无奈失去正确的解决，这时宕掉的实例会被踢出集群，此时算法变成 hash(userId) mod N-1，用户信息可能就不再在同一个库中了。
2、范畴限定算法
依照 工夫区间 或 ID 区间 来切分，比方：咱们切分的是用户表，能够定义每个库的 User 表里只存 10000 条数据，第一个库只存 userId 从 1 ~ 9999 的数据，第二个库存 userId 为 10000 ~ 20000，第三个库存 userId 为 20001~ 30000…… 以此类推，按工夫范畴也是同理。
长处：
- 单表数据量是可控的
- 程度扩大简略只需减少节点即可，无需对其余分片的数据进行迁徙
- 能疾速定位要查问的数据在哪个库
毛病：
- 因为间断分片可能存在数据热点，比方按工夫字段分片，可能某一段时间内订单骤增，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查问。
分库分表的难点
1、分布式事务
因为表散布在不同库中，不可避免会带来跨库事务问题。个别可应用 “三阶段提交 “ 和 “ 两阶段提交” 解决，然而这种形式性能较差，代码开发量也比拟大。通常做法是做到最终一致性的计划，如果不奢求零碎的实时一致性，只有在容许的时间段内达到最终一致性即可，采纳事务弥补的形式。
这里我利用阿里的分布式事务框架Seata 来做分布式事务的治理，后边会结合实际案例。
2、分页、排序、跨库联结查问
分页、排序、联结查问是开发中应用频率十分高的性能，但在分库分表后，这些看似一般的操作却是让人十分头疼的问题。将扩散在不同库中表的数据查问进去，再将所有后果进行汇总整顿后提供给用户。
3、分布式主键
分库分表后数据库的自增主键意义就不大了，因为咱们不能依附单个数据库实例上的自增主键来实现不同数据库之间的全局惟一主键，此时一个可能生成全局惟一 ID 的零碎是十分必要的，那么这个全局惟一 ID 就叫 分布式 ID。
4、读写拆散
不难发现大部分支流的关系型数据库都提供了主从架构的高可用计划，而咱们须要实现 读写拆散 + 分库分表，读库与写库都要做分库分表处理，后边会有具体实战案例。
5、数据脱敏
数据脱敏，是指对某些敏感信息通过脱敏规定进行数据转换，从而实现敏感隐衷数据的牢靠爱护，如身份证号、手机号、卡号、账号密码等个人信息，个别这些都须要进行做脱敏解决。
分库分表工具
我还是那句话，尽量不要本人造轮子，因为本人造的轮子可能不那么圆，业界曾经有了很多比拟成熟的分库分表中间件，咱们依据本身的业务需要筛选，将更多的精力放在业务实现上。
sharding-jdbc（当当）TSharding（蘑菇街）Atlas（奇虎 360）Cobar（阿里巴巴）MyCAT（基于 Cobar）Oceanus（58 同城）Vitess（谷歌）
为什么选 sharding-jdbc
sharding-jdbc 是一款轻量级 Java 框架，以 jar 包模式提供服务，是属于客户端产品不须要额定部署，它相当于是个增强版的 JDBC 驱动；相比之下像 Mycat 这类须要独自的部署服务的服务端产品，就稍显简单了。况且我想把更多精力放在实现业务，不想做额定的运维工作。
sharding-jdbc的兼容性也十分弱小，实用于任何基于JDBC的ORM框架，如：JPA，Hibernate，Mybatis，Spring JDBC Template或间接应用的JDBC。- 完满兼容任何第三方的数据库连接池，如：
DBCP，C3P0，BoneCP，Druid，HikariCP等，简直对所有关系型数据库都反对。
不难发现的确是比拟弱小的一款工具，而且它对我的项目的侵入性很小，简直不必做任何代码层的批改，也无需批改 SQL 语句，只需配置待分库分表的数据表即可。
总结
简略的回顾一下分库分表的基础知识，接下来的文章会配合实战我的项目介绍 sharding-jdbc 在分库分表中的各个性能点。
原文链接
本文为阿里云原创内容，未经容许不得转载。