Sharding-JDBC

一、概念先行 1）SQL相关的 逻辑表：水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为2张表，分别是t_order_0到t_order_1，他们的逻辑表名为t_order。 真实表：在分片的数据库中真实存在的物理表。例：示例中的t_order_0到t_order_1 数据节点：数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0；ds_0.t_order_1； 绑定表：指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。 广播表：指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表，示例中的t 2）分片相关 分片键：用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。 分片算法：通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片

一、分布式简介 1、架构简介 现在的互联网，几乎常见的复杂系统都会使用分布式架构，如果在不清楚概念之前，刚接触分布式架构这个名词会感觉十分的高大上，其实在对比单服务，集群服务之后，你就会发现本质上都是一样的。 絮叨一句 ：所谓Java架构师，基本就是看被单服务，集群，分布式不断暴打的频率，架构师因为被虐频率高，自然做出来的系统架构坑少，新手不能做架构的原因，所以你该懂的。 言归正传，分布式架构对于Java开发来说基本算是分水岭，能不能从开发层面跳出来，就看你工作个三五年之后，对分布式系统理解到什么程度。单服务应用，基于单服务做集群化部署，这种操作运维可以自行搭建环境，所以基本对能力要求不算高。但是如何设计出弹性、配置化、分布化、高性能、高容错、安全的分布式系统，的确是一件很有挑战的事情。 2、集群和分布式 首先需要理清楚单服务，集群，分布式这几种不同架构的区别。 单服务和集群 一张图，你品，你细品： 业务体量小，所有服务和应用部署在一台服务上，节省成本，这是单服务结构。当业务量逐渐增大，把一台服务进行水平扩展，做一个服务群，每台服务称为集群的一个节点，到这就是集群服务。集群服务要面对的一个问题就是：请求分配，自然需要一个调度组件来均衡服务器压力，这也被称为负载均衡。 补刀一句 ：做到集群模式的应用，在程序员面试的时候已经会被拿来做高格调的自吹自擂了，其实单服务和集群的本质区别就是

架构 在数据量不是很多的情况下，我们可以将数据库进行读写分离，以应对高并发的需求，通过水平扩展从库，来缓解查询的压力。如下： 在数据量达到500万的时候，这时数据量预估千万级别，我们可以将数据进行分表存储。 在数据量继续扩大，这时可以考虑分库分表，将数据存储在不同数据库的不同表中，如下： 案例详解 本案例有6个数据库，两个主库，四个从库，信息如下： 数据库类型 数据库 IP 主 cool 47.98.183.0 从 cool 101.37.175.23 从 cool 120.27.250.228 主 cool2 47.98.183.0 从 cool2 101.37.175.23 从 cool2 120.27.250.228 在主库主机的Mysql执行以下脚本，分别为数据库cool和cool2创建5个表，这5个表分别为user_0、user_1、user_2、user_3、user_4。 分库需要注意ID的自增问题，我这里直接使用分布式生成ID 执行的脚本如下： USE `cool`; /*Table structure for table `user_0` */ DROP TABLE IF EXISTS `user_0`; CREATE TABLE `user_0` ( `id` varchar(20) NOT NULL, `username` varchar(12) NOT

引言 微服务、分布式大行其道的当下，中、高级Java工程师面试题中高并发、大数据量、分库分表等已经成 了面试的高频词汇，这些知识不了解面试通过率不会太高。你可以不会用，但你不能不知道，就是这么 一种现状。技术名词大多晦涩难懂，不要死记硬背理解最重要，当你捅破那层窗户纸，发现其实它也就 那么回事。 一、为什么要分库分表 关系型数据库以MySQL为例，单机的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶 颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。一旦数据量朝着千万 以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响 应速度，缩短查询时间，这时候就需要进行分库分表。 二、如何分库分表 分库分表就是要将大量数据分散到多个数据库中，使每个数据库中数据量小响应速度快，以此来提升数 据库整体性能。核心理念就是对数据进行切分（Sharding），以及切分后如何对数据的快速定位与整合。 针对数据切分类型，大致可以分为：垂直（纵向）切分和水平（横向）切分两种。 1、垂直切分 垂直切分又细分为垂直分库和垂直分表 垂直分库 垂直分库是基于业务分类的，和我们常听到的微服务治理观念很相似，每一个独立的服务都拥有自己的 数据库，需要不同业务的数据需接口调用。而垂直分库也是按照业务分类进行划分，每个业务有独立数 据库，这个比较好理解。

读写分离 在上一篇文章介绍了如何使用Sharing-JDBC实现数据库的读写分离。读写分离的好处就是在并发量比较大的情况下，将查询数据库的压力 分担到多个从库中，能够满足高并发的要求。比如上一篇实现的那样，架构图如下： 数据分表 当数据量比较大的时候，比如单个表的数据量超过了500W的数据，这时可以考虑将数据存储在不同的表中。比如将user表拆分为四个表user_0、user_1、 user_2、user_3装在四个表中。此时如图所示： 案例详解 和上一篇文章使用的数据库是同一个数据库，数据库信息如下： 数据库类型 数据库 IP 主 cool 47.98.183.0 从 cool 101.37.175.23 从 cool 120.27.250.228 在主库初始化Mysql数据的脚本，初始化完后，从库也会创建这些表，脚本信息如下： USE `cool`; /*Table structure for table `user_0` */ DROP TABLE IF EXISTS `user_0`; CREATE TABLE `user_0` ( `id` int(12) NOT NULL AUTO_INCREMENT, `username` varchar(12) NOT NULL, `password` varchar(30) NOT NULL, PRIMARY KEY (`id`)

主流Java数据库连接池比较及前瞻 https://www.jianshu.com/p/b9b98ac3e010 一、主流数据库连接池 C3p0: 实现数据源和JNDI绑定，支持JDBC3规范和JDBC2的标准扩展。Hibernate、Spring使用。单线程，性能较差，适用于小型系统，代码600KB左右。 DBCP (Database Connection Pool):Apache的， Jakarta commons-pool对象池机制，Tomcat使用。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar，预先将数据库连接放内存中，建立数据库连接时，直接到连接池中申请，用完放回。单线程，并发量低，性能不好，适用于小型系统。 Tomcat Jdbc Pool：Tomcat在7.0以前都是使用，单线程，保证线程安全会锁整个连接池，性能差，超过60个类复杂。Tomcat从7.0开始叫做Tomcat jdbc pool，基于Tomcat JULI，使用Tomcat日志框架，完全兼容dbcp，异步方式获取连接，支持高并发应用环境，核心文件8个，支持JMX，支持XA Connection。 BoneCP：高效、免费。设计提高性能，速度最快，高度可扩展：集成Hibernate和DataNucleus中

一、为什么需要分布式数据据库 随着计算机和信息技术的迅猛发展，行业应用系统的规模迅速扩大，行业应用所产生的数据量呈爆炸式增长，动辄达到数百TB甚至数百PB的规模，已远远超出传统计算技术和信息系统的处理能力，集中式数据库面对大规模数据处理逐渐表现出其局限性。因此，人们希望寻找一种能快速处理数据和及时响应用户访问的方法，也希望对数据进行集中分析、管理和维护。这已经成为迫切需求。 分布式数据库是在集中式数据库的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库是指数据在物理上分布而在逻辑上集中管理的数据库系统。物理上分布是指数据分布在物理位置不同并由网络连接的节点或站点上;逻辑上集中是指各数据库节点之间的逻辑上是一个整体，并由统一的数据库管理系统管理。不同的节点分布可以跨不同的机房、城市甚至国家。 二、分布式数据库的特点 分布式数据库具有透明性、数据冗余性、易于扩展性、自治性等特点，还具有经济、性能优越、响应速度更快、灵活的体系结构、易于集成现有系统等特点。 分布式数据库尽管有着天生的高贵血统，但它依赖调整网络，对事务的处理远没有传统数据库成熟，在很长一段时间内分布式数据存储将与传统数据存储共存。 三、MyCat数据库中间件简介 MyCat是一个彻底开源的面向企业应用开发的大数据库集群，支持事务、ACID，是可以替代MySQL的加强版数据库

《 SpringBoot2.X心法总纲》 （本篇博客已于2019-08-28优化更新） 序言：当当开发的一个中间件, sharding-jdbc官网API ，听说能用它也能读写分离,但这一篇博客主要讲述的是分库分表的功能。 1、Sharding-JDBC 1.1 历史由来 第一版的分库分表并不是现有的Sharding-JDBC，而是当当的一个内部框架ddframe的数据库模块， dd-rdb的其中一项功能就是分库，没有分表功能，当时只是做了简单的SQL解析。后来随着ddframe被各个 团队采用，只分库的需求渐渐不够用了，而dd-rdb里面有大量的数据库ORM相关的东西，为了使分库分表这 一核心需求更加纯粹，我们才将其中的分片的部分单独提炼出来并命名为Sharding-JDBC，用于在Java的 JDBC层面提供一层驱动，无缝的处理这方面的需求。 1.2 使用场景 对于关系型数据库数据量很大的情况，需要进行水平拆库和拆表，这种场景很适合使用Sharding-JDBC。 举例说明：假设有一亿数据的用户库，放在 MySQL 数据库里查询性能会比较低，而采用水平拆库，将其分为10 个库，根据用户的ID模10，这样数据就能比较平均的分在10个库中，每个库只有1000w记录，查询性能会大大提 升。分片策略类型非常多，大致分为Hash + Mod、Range、Tag 等。Sharding

在传统企业软件开发中，主键自动生成技术是基本需求，各个数据库对于该自增主键的需求提供了相应的支持，如MySQL的自增键。对于MySQL而言，分库分表之后，不同库、不同表生成全局唯一的主键是非常麻烦的事情。因为同一个逻辑表内的不同物理表之间的自增主键是无法互相感知的，这样会生成重复的主键。 目前有许多第三方解决方案可以完美解决这个问题，比如UUID等依靠特定算法自生成不重复键，或者通过引入主键生成服务（Redis或者ZooKeeper）等。 Sharding-JDBC提供了注解生成接口KeyGenerator。各个实现类通过实现generateKey()方法即可对外提供生成主键的功能。下面分析Sharding-JDBC分布式主键的使用。 DefaultKeyGenerator是Sharding-JDBC默认的主键生成器 。该主键生成器采用 Twitter Snowflake 算法实现生成64位的Long型编号。国内很多大型互联网公司发号器服务基于该算法加部分改造实现。下面分析DefaultKeyGenerator产生的编号的组成。 DefaultKeyGenerator生成的64位Long型编号的组成如图所示。 64位Long型编号中各个部分的如表所示。 位数 含义 取值范围 1 符号位 0 41 时间戳 从2016-11-01 00:00:00 开始的毫秒数，支持约70年 10

1 介绍 Sharding-JDBC是开源的数据库中间件。Sharding-JDBC定位为轻量级数据库驱动，由客户端直连数据库，以jar包形式提供服务，没有使用中间层，无须额外部署，无须其他依赖。Sharding-JDBC可以实现旧代码迁移零成本的目标。Sharding-JDBC与MyCat不同，MyCat本质上是一种数据库代理。 2 实战SQL 2.1 有2个库 库名 表名 shop_0 shop_info_0、shop_info_1 shop_1 shop_info_0、shop_info_1 2.2 表结构SQL DROP DATABASE IF EXISTS `shop_0`; CREATE DATABASE `shop_0`; USE `shop_0`; CREATE TABLE `shop_info_0` ( `shop_id` bigint(80) NOT NULL, `shop_name` varchar(45) DEFAULT NULL, `account` varchar(45) NOT NULL, PRIMARY KEY (`shop_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `shop_info_1` ( `shop_id` bigint(80) NOT NULL, `shop_name`