Sharding-JDBC从入门到精通（2）- Sharding-JDBC 介绍
一、概述-分库分表所带来的问题
1、分库分表带来的问题
分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力，突破网络 IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。
2、分库分表带来的问题 ：事务一致性问题
由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。
3、分库分表带来的问题 ：跨节点关联查询
1）在没有分库前，我们检索商品时可以通过以下 SQL 对店铺信息进行关联询
SELECT P.*,r.[地理区域名称],5.[店铺名称],s.[信誉]FROM「商品信息]P
LEFT J0IN[地理区域]r ON p.[产地]=r.[地理区域编码]LEFT JOIN[店铺信息]s ON p.id = s.[所属店铺]WHERE...ORDER BY...LIMIT...
2）但垂直分库后[商品信息]和[店铺信息]不在一个数据库，甚至不在一台服务器,无法进行关联查询。
3）可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据 id, 然后根据 id 发起第二次请求得到关联数据，最后将获得到的数据进行拼装。
4、分库分表带来的问题 ：跨节点分页、排序函数
1）跨节点多库进行查询时，limit 分页、order by 排序等问题,就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。
2）如，进行水平分库后的商品库，按 ID 倒序排序分页，取第一页:
3）以上流程是取第一页的数据，性能影响不大，但由于商品信息的分布在各数据库的数据可能是随机的，如果是取第 N 页，需要将所有节点前 N 页数据都取出来合并，再进行整体的排序，操作效率可想而知。所以请求页数越大，系统的性能也会越差。
4）在使用 Max、Min、Sum、Count 之类的函数进行计算的时候，与排序分页同理,也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。
5、分库分表带来的问题 ：主键避重
在分库分表环境中，由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地，某个分区数据库生成的 ID 无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。
6、分库分表带来的问题 ：公共表
1）实际的应用场景中，参数表、数据字典表等都是数据量较小,变动少,而且属于高频联合查询的依赖表。电商业务例子中地理区域表也属于此类型。
2）可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。
3）由于分库分表之后，数据被分散在不同的数据库、服务器。因此，对数据的操作也就无法通过常规方式完成，并且它还带来了一系列的问题。好在，这些问题不是所有都需要我们在应用层面上解决，市面上有很多中间件可供我们选择，其中 Sharding-JDBC 使用流行度较高。
二、概述-Sharding-JDBC 介绍
1、sharding-JDBc 介绍
Sharding-JDBC, 它定位为轻量级 java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖,可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
1）sharding-JDBc 是当当网研发的开源分布式数据库中间件,从 3.0 开始 Sharding-JDBC 被包含在 shardingSphere 中，之后该项目进入进入 Apache 孵化器，4.0 版本之后的版本为 Apache 版本。
2）ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar (计划中)这3款相互独立的产品组成。
他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各种多样化的应用场景。
3）ShardingSphere 官方地址 :
https://shardingsphere.apache.org/document/current/cn/overview/
4）Sharding-JDBC 的核心功能为数据分片和读写分离,通过 Sharding:JDBc,应用可以透明的使用 Jdbc 访问已经分库分表、读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。
- 适用于任何基于 java 的 ORM 框架，如:Hibernate,Mybatis,SpringJDBC Template 或直接使用 JDBC。
- 基于任何第三方的数据库连接池，如:DBCP, C3P0,BoneCP, Druid, HikariCp 等。
- 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL
2、Sharding-JDBC 的工作方式
使用 Sharding-Jdbc 前需要人工对数据库进行分库分表，在应用程序中加入 Sharding-Jdbc 的 jar 包，应用程序通过 Sharding-Jdbc 操作分库分表后的数据库和数据表，由于 Sharding-Jdbc 是对 Jdbc 驱动的增强，使用 Sharding-JDBC 就像使用 JDBC 驱动一样，在应用程序中是无需指定具体要操作的分库和分表的。
三、概述-Sharding-JDBC 介绍-与 jdbc 性能对比
1、Sharding-JDBC 与 jdbc 性能对比：性能损耗测试
服务器资源充足、并发数相同，比较 JDBC 和 Sharding-JDBC 性能损耗，Sharding-JDBC 相对 IDBC 损耗不超过 7%。
基准测试性能对比
| 业务场景 | JDBC | Sharding-JDBC1.5.2 | sharding-JDBC1.5.2/JDBC损耗 | |
|---|---|---|---|---|
| 单库单表查询 | 493 | 470 | 4.7% | |
| 单库单表更新 | 6682 | 6303 | 5.7% | |
| 单库单表插入 | 6855 | 6375 | 7% | |
| 业务场景 | 业务平均响应时间(ms) | 业务TPS | ||
|---|---|---|---|---|
| JDBC单库单表查询 | 7 | 493 | ||
| Sharding-JDBC 1.5.2单库单表查询 | 8 | 470 | ||
2、性能对比测试:
服务器资源使用到极限，相同的场景 JDBC 与 Sharding-JDBC 的吞吐量相当。
3、性能对比测试:
服务器资源使用到极限，Shtrding-JDBC 采用分库分表后，Sharding-JDBC 吞吐量较 JDBC 不分表有接近 2 倍的提升。
4、JDBC 单库两库表与 Sharding-JDBC 两库各两表对比
| 业务场景 | JDBC单库两表 | Sharding-JDBC两库各两表 | 性能提升至 | |
|---|---|---|---|---|
| 查询 | 1736 | 3331 | 192% | |
| 更新 | 9170 | 17997 | 196% | |
| 插入 | 11574 | 23043 | 199% | |
5、JDBC 单库单表与 Sharding-JDBC 两库各一表对比
| 业务场景 | JDBC单库单表 | Sharding-JDBC两库各一表 | 性能提升至 | |
|---|---|---|---|---|
| 查询 | 1586 | 2944 | 185% | |
| 更新 | 9548 | 18561 | 194% | |
上一节关联链接请点击
# Sharding-JDBC从入门到精通（1）- 概述-分库分表