SpringBoot + Sharding JDBC，一文搞定分库分表、读写分离
sharding-jdbc最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为shardingsphere，2020年4⽉16日正式成为 apache 软件基金会的顶级项目。
shardingsphere-jdbc定位为轻量级java框架，在java的jdbc层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，可理解为增强版的jdbc驱动，完全兼容jdbc和各种orm框架。
随着版本的不断更迭 shardingsphere 的核心功能也变得多元化起来。
从最开始 sharding-jdbc 1.0 版本只有数据分片，到 sharding-jdbc 2.0 版本开始支持数据库治理（注册中心、配置中心等等），再到 sharding-jdbc 3.0版本又加分布式事务 （支持 atomikos、narayana、bitronix、seata），如今已经迭代到了 sharding-jdbc 4.0 版本。
现在的 shardingsphere 不单单是指某个框架而是一个生态圈，这个生态圈sharding-jdbc、sharding-proxy和sharding-sidecar这三款开源的分布式数据库中间件解决方案所构成。
shardingsphere 的前身就是 sharding-jdbc，所以它是整个框架中最为经典、成熟的组件，先从 sharding-jdbc 框架入手学习分库分表。
1核心概念
分库分表
分库，显而易见，就是一个数据库分成多个数据库，部署到不同机器。
分表，就是一个数据库表分成多个表。
分片
一般在提到分库分表的时候，大多是以水平切分模式（水平分库、分表）为基础来说的，数据分片将原本一张数据量较大的表例如 t_order 拆分生成数个表结构完全一致的小数据量表 t_order_0、t_order_1、···、t_order_n，每张表只存储原大表中的一部分数据，当执行一条sql时会通过分库策略、分片策略将数据分散到不同的数据库、表内。
数据节点
数据节点是分库分表中一个不可再分的最小数据单元（表），它由数据源名称和数据表组成，例如上图中 order_db_1.t_order_0、order_db_2.t_order_1 就表示一个数据节点。
逻辑表
逻辑表是指一组具有相同逻辑和数据结构表的总称。
比如将订单表 t_order 拆分成 t_order_0 ··· t_order_9 等 10张表。
此时会发现分库分表以后数据库中已不在有 t_order 这张表，取而代之的是 t_order_n，但在代码中写 sql 依然按 t_order 来写。此时 t_order 就是这些拆分表的逻辑表。
真实表
真实表也就是上边提到的 t_order_n 数据库中真实存在的物理表。
分片键
用于分片的数据库字段。将 t_order 表分片以后，当执行一条sql时，通过对字段 order_id 取模的方式来决定，这条数据该在哪个数据库中的哪个表中执行，此时 order_id 字段就是 t_order 表的分片健。
这样以来同一个订单的相关数据就会存在同一个数据库表中，大幅提升数据检索的性能，不仅如此 sharding-jdbc 还支持根据多个字段作为分片健进行分片。
分片算法
上边提到可以用分片健取模的规则分片，但这只是比较简单的一种，在实际开发中还希望用 >=、、、=、， =，， =， {t_order_id % 4} 代表 t_order 对其字段 t_order_id取模，拆分成4张表，而表名分别是t_order_0 到 t_order_3。
4、hint分片策略
hint分片策略，对应上边的hint分片算法，通过指定分片健而非从 sql中提取分片健的方式进行分片的策略。
分布式主键
数据分⽚后，不同数据节点⽣成全局唯⼀主键是⾮常棘⼿的问题，同⼀个逻辑表（t_order）内的不同真实表（t_order_n）之间的⾃增键由于⽆法互相感知而产⽣重复主键。
尽管可通过设置⾃增主键 初始值 和 步⻓ 的⽅式避免id碰撞，但这样会使维护成本加大，乏完整性和可扩展性。如果后去需要增加分片表的数量，要逐一修改分片表的步长，运维成本非常高，所以不建议这种方式。
为了让上手更加简单，apacheshardingsphere 内置了uuid、snowflake 两种分布式主键⽣成器，默认使用雪花算法（snowflake）⽣成64bit的⻓整型数据。不仅如此它还抽离出分布式主键⽣成器的接口，方便实现自定义的自增主键生成算法。
广播表
广播表：存在于所有的分片数据源中的表，表结构和表中的数据在每个数据库中均完全一致。一般是为字典表或者配置表 t_config，某个表一旦被配置为广播表，只要修改某个数据库的广播表，所有数据源中广播表的数据都会跟着同步。
绑定表
绑定表：那些分片规则一致的主表和子表。比如：t_order 订单表和 t_order_item 订单服务项目表，都是按 order_id 字段分片，因此两张表互为绑定表关系。
那绑定表存在的意义是啥呢？
通常在业务中都会使用 t_order 和 t_order_item 等表进行多表联合查询，但由于分库分表以后这些表被拆分成n多个子表。如果不配置绑定表关系，会出现笛卡尔积关联查询，将产生如下四条sql。
select * from t_order_0 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_0 o join t_order_item_1 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_1 i on o.order_id=i.order_id
而配置绑定表关系后再进行关联查询时，只要对应表分片规则一致产生的数据就会落到同一个库中，那么只需 t_order_0 和 t_order_item_0 表关联即可。
select * from t_order_0 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_1 i on o.order_id=i.order_id
注意：在关联查询时 t_order 它作为整个联合查询的主表。所有相关的路由计算都只使用主表的策略，t_order_item 表的分片相关的计算也会使用 t_order 的条件，所以要保证绑定表之间的分片键要完全相同。
2mysql主从复制
docker配置mysql主从复制
创建主服务器所需目录
mkdir -p /usr/local/mysqldata/master/cnfmkdir -p /usr/local/mysqldata/master/data
定义主服务器配置文件
vim /usr/local/mysqldata/master/cnf/mysql.cnf[mysqld]## 设置server_id,注意要唯一server-id=1## 开启binloglog-bin=mysql-bin## binlog缓存binlog_cache_size=1m## binlog格式(mixed、statement、row,默认格式是statement)binlog_format=mixed
创建并启动mysql主服务
docker run -itd -p 3306:3306 --name master -v /usr/local/mysqldata/master/cnf:/etc/mysql/conf.d -v /usr/local/mysqldata/master/data:/var/lib/mysql -e mysql_root_password=123456 mysql:5.7
添加复制master数据的用户reader，供从服务器使用
[root@aliyun /]# docker pscontainer id image command created status ports names6af1df686fff mysql:5.7 docker-entrypoint... 5 seconds ago up 4 seconds 0.0.0.0:3306->3306/tcp, 33060/tcp master[root@aliyun /]# docker exec -it master /bin/bashroot@41d795785db1:/# mysql -u root -p123456mysql> grant replication slave on *.* to 'reader'@'%' identified by 'reader';query ok, 0 rows affected, 1 warning (0.00 sec)mysql> flush privileges;query ok, 0 rows affected (0.00 sec)
创建从服务器所需目录，编辑配置文件
mkdir /usr/local/mysqldata/slave/cnf -pmkdir /usr/local/mysqldata/slave/cnf -pvim /usr/local/mysqldata/slave/cnf/mysql.cnf[mysqld]## 设置server_id,注意要唯一server-id=2## 开启binlog,以备slave作为其它slave的master时使用log-bin=mysql-slave-bin## relay_log配置中继日志relay_log=edu-mysql-relay-bin## 如果需要同步函数或者存储过程log_bin_trust_function_creators=true## binlog缓存binlog_cache_size=1m## binlog格式(mixed、statement、row,默认格式是statement)binlog_format=mixed## 跳过主从复制中遇到的所有错误或指定类型的错误,避免slave端复制中断## 如:1062错误是指一些主键重复,1032错误是因为主从数据库数据不一致slave_skip_errors=1062
创建并运行mysql从服务器
docker run -itd -p 3307:3306 --name slaver -v /usr/local/mysqldata/slave/cnf:/etc/mysql/conf.d -v /usr/local/mysqldata/slave/data:/var/lib/mysql -e mysql_root_password=123456 mysql:5.7
在从服务器上配置连接主服务器的信息
首先主服务器上查看master_log_file、master_log_pos两个参数，然后切换到从服务器上进行主服务器的连接信息的设置
主服务上执行：
root@6af1df686fff:/# mysql -u root -p123456mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| file | position | binlog_do_db | binlog_ignore_db | executed_gtid_set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 591 | | | |+------------------+----------+--------------+------------------+-------------------+1 row in set (0.00 sec)
docker查看主服务器容器的ip地址
[root@aliyun /]# docker inspect --format='{{.networksettings.ipaddress}}' master172.17.0.2
从服务器上执行：
[root@aliyun /]# docker exec -it slaver /bin/bashroot@fe8b6fc2f1ca:/# mysql -u root -p123456 mysql> change master to master_host='172.17.0.2',master_user='reader',master_password='reader',master_log_file='mysql-bin.000003',master_log_pos=591;
从服务器启动i/o 线程和sql线程
mysql> start slave;query ok, 0 rows affected, 1 warning (0.00 sec)mysql> show slave statusg*************************** 1. row *************************** slave_io_state: waiting for master to send event master_host: 172.17.0.2 master_user: reader master_port: 3306 connect_retry: 60 master_log_file: mysql-bin.000003 read_master_log_pos: 591 relay_log_file: edu-mysql-relay-bin.000002 relay_log_pos: 320 relay_master_log_file: mysql-bin.000003 slave_io_running: yes slave_sql_running: yes
slave_io_running: yes，slave_sql_running: yes 即表示启动成功
binlog和redo log回顾
redo log（重做日志）
innodb首先将redo log放入到redo log buffer，然后按一定频率将其刷新到redo log file
下列三种情况下会将redo log buffer刷新到redo log file：
master thread每一秒将redo log buffer刷新到redo log file
每个事务提交时会将redo log buffer刷新到redo log file
当redo log缓冲池剩余空间小于1/2时，会将redo log buffer刷新到redo log file
mysql里常说的wal技术，全称是write ahead log，即当事务提交时，先写redo log，再修改页。也就是说，当有一条记录需要更新的时候，innodb会先把记录写到redo log里面，并更新buffer pool的page，这个时候更新操作就算完成了
buffer pool是物理页的缓存，对innodb的任何修改操作都会首先在buffer pool的page上进行，然后这样的页将被标记为脏页并被放到专门的flush list上，后续将由专门的刷脏线程阶段性的将这些页面写入磁盘
innodb的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1gb，循环使用，从头开始写，写到末尾就又回到开头循环写（顺序写，节省了随机写磁盘的io消耗）
write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。check point是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件
write pos和check point之间空着的部分，可以用来记录新的操作。如果write pos追上check point，这时候不能再执行新的更新，需要停下来擦掉一些记录，把check point推进一下
当数据库发生宕机时，数据库不需要重做所有的日志，因为check point之前的页都已经刷新回磁盘，只需对check point后的redo log进行恢复，从而缩短了恢复的时间
当缓冲池不够用时，根据lru算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行check point，将脏页刷新回磁盘
binlog（归档日志）
mysql整体来看就有两块：一块是server层，主要做的是mysql功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。redo log是innodb引擎特有的日志，而server层也有自己的日志，称为binlog
binlog记录了对mysql数据库执行更改的所有操作，不包括select和show这类操作，主要作用是用于数据库的主从复制及数据的增量恢复
使用mysqldump备份时，只是对一段时间的数据进行全备，但是如果备份后突然发现数据库服务器故障，这个时候就要用到binlog的日志了
binlog格式有三种：statement，row，mixed
statement模式：binlog里面记录的就是sql语句的原文。优点是并不需要记录每一行的数据变化，减少了binlog日志量，节约io，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致
row模式：不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了，解决了statement模式下出现master-slave中的数据不一致。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨
mixed模式：以上两种模式的混合使用，一般的复制使用statement模式保存binlog，对于statement模式无法复制的操作使用row模式保存binlog，mysql会根据执行的sql语句选择日志保存方式
redo log和binlog日志的不同
redo log是innodb引擎特有的；binlog是mysql的server层实现的，所有引擎都可以使用
redo log是物理日志，记录的是在某个数据也上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给id=2这一行的c字段加1
redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志
两阶段提交
create table t(id int primary key, c int);update t set c=c+1 where id=2;
执行器和innodb引擎在执行这个update语句时的内部流程：
执行器先找到引擎取id=2这一行。id是主键，引擎直接用树搜索找到这一行。如果id=2这一行所在的数据也本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回
执行器拿到引擎给的行数据，把这个值加上1，得到新的一行数据，再调用引擎接口写入这行新数据
引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务
执行器生成这个操作的binlog，并把binlog写入磁盘
执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交状态，更新完成
update语句的执行流程图如下，图中浅色框表示在innodb内部执行的，深色框表示是在执行器中执行的
将redo log的写入拆成了两个步骤：prepare和commit，这就是两阶段提交
mysql主从复制原理
从库b和主库a之间维持了一个长连接。主库a内部有一个线程，专门用于服务从库b的这个长连接。一个事务日志同步的完整过程如下：
在从库b上通过change master命令，设置主库a的ip、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量
在从库b上执行start slave命令，这时从库会启动两个线程，就是图中的i/o线程和sql线程。其中i/o线程负责与主库建立连接
主库a校验完用户名、密码后，开始按照从库b传过来的位置，从本地读取binlog，发给b
从库b拿到binlog后，写到本地文件，称为中继日志
sql线程读取中继日志，解析出日志里的命令，并执行
由于多线程复制方案的引入，sql线程演化成了多个线程。
主从复制不是完全实时地进行同步，而是异步实时。这中间存在主从服务之间的执行延时，如果主服务器的压力很大，则可能导致主从服务器延时较大。
3为什么需要分库分表？
首先要明确一个问题，单一的数据库是否能够满足公司目前的线上业务需求，比如用户表，可能有几千万，甚至上亿的数据，只是说可能，如果有这么多用户，那必然是大公司了，那么这个时候，如果不分表也不分库的话，那么数据了上来的时候，稍微一个不注意，mysql单机磁盘容量会撑爆，但是如果拆成多个数据库，磁盘使用率大大降低。
这样就把磁盘使用率降低，这是通过硬件的形式解决问题，如果数据量是巨大的，这时候，sql 如果没有命中索引，那么就会导致一个情况，查这个表的sql语句直接把数据库给干崩了。
即使sql命中了索引，如果表的数据量 超过一千万的话， 查询也是会明显变慢的。这是因为索引一般是b+树结构，数据千万级别的话，b+树的高度会增高，查询自然就变慢了，当然，这是题外话了。
4mysql分库分表原理
分库分表
水平拆分：同一个表的数据拆到不同的库不同的表中。可以根据时间、地区或某个业务键维度，也可以通过hash进行拆分，最后通过路由访问到具体的数据。拆分后的每个表结构保持一致
垂直拆分：就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，可以根据业务维度进行拆分，如订单表可以拆分为订单、订单支持、订单地址、订单商品、订单扩展等表；也可以，根据数据冷热程度拆分，20%的热点字段拆到一个表，80%的冷字段拆到另外一个表
不停机分库分表数据迁移
一般数据库的拆分也是有一个过程的，一开始是单表，后面慢慢拆成多表。那么就看下如何平滑的从mysql单表过度到mysql的分库分表架构
利用mysql+canal做增量数据同步，利用分库分表中间件，将数据路由到对应的新表中
利用分库分表中间件，全量数据导入到对应的新表中
通过单表数据和分库分表数据两两比较，更新不匹配的数据到新表中
数据稳定后，将单表的配置切换到分库分表配置上
5分库分表方案
分库分表方案，不外乎就两种，一种是垂直切分，一种是水平切分。
但是总有做开发的小伙伴不知道这垂直切分和水平切分到底是什么样的，为什么垂直切分，为什么水平切分，什么时候应该选择垂直切分，什么时候应该选择水平切分。
有人是这么说的，垂直切分是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。
有些人不理解这个，实际上垂直切分也是有划分的，上面描述的是垂直切分数据库，可能容易让很多人不太理解，但是如果是垂直切分表，那么肯定百分之90的人都能理解。
垂直切分
有一张order表，表中有诸多记录，比如设计这么一张简单的表。
id order_id order_date order_type order_state
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311 支付宝 1
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433 微信 2
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544 现金 2
以上是简化版order表，如果想要垂直切分，那么应该怎么处理？
直接拆分成2个表，这时候就直接就一分为2 ，咔的一下拆分成两个表
order1
id order_id order_date
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544
order2
id order_type order_state
1 支付宝 1
2 微信 2
3 现金 2
这时候主键id保持的时一致的，而这个操作，就是垂直拆分，分表的操作。
既然说了垂直拆分，那么必然就有水平拆分，
什么是水平拆分呢？
实际上水平拆分的话，那真的是只有一句话。
水平切分
按照数据来拆分
水平拆分数据库：将一张表的数据 ( 按照数据行) 分到多个不同的数据库。每个库的表结构相同，每个库都只有这张表的部分数据，当单表的数据量过大，如果继续使用水平分库，那么数据库的实例 就会不断增加，不利于系统的运维。这时候就要采用水平分表。
水平拆分表：将一张表的数据 ( 按照数据行) ，分配到同一个数据库的多张表中，每个表都只有一部分数据。
来看看order表进行水平拆分的话，是什么样子的。
order1
id order_id order_date order_type order_state
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311 支付宝 1
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433 微信 2
order2
id order_id order_date order_type order_state
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544 现金 2
实际上就是水平的把表数据给分成了2份，这么看起来是不是就很好理解了。
6分库分表带来的问题
事务问题
首先，分库分表最大的隐患就是，事务的一致性， 当需要更新的内容同时分布在不同的库时，不可避免的会产生跨库的事务问题。
原来在一个数据库操 作，本地事务就可以进行控制，分库之后 一个请求可能要访问多个数据库，如何保证事务的一致性，目前还没有简单的解决方案。
无法联表的问题
还有一个就是，没有办法进行联表查询了，因为，原来在一个库中的一些表，被分散到多个库，并且这些数据库可能还不在一台服务器，无法关联查询，所以相对应的业务代码可能就比较多了。
分页问题
分库并行查询时，如果用到了分页，每个库返回的结果集本身是无序的，只有将多个库中的数据先查出来，然后再根据排序字段在内存中进行排序，如果查询结果过大也是十分消耗资源的。
分库分表的技术
目前比较流行的就两种，一种是mycat，另外一种则是sharding-jdbc，都是可以进行分库的，
mycat是一个数据库中间件，sharding-jdbc是以 jar 包提供服务的jdbc框架。
mycat和sharding-jdbc 实现原理也是不同：
mycat的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的sql语句，首先对sql语句做了一些特定的分析：如分库分表分析、路由分析、读写分离分析、缓存分析等，然后将此sql发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
而sharding-jdbc的原理是接受到一条sql语句时，会陆续执行sql解析 => 查询优化 => sql路由 => sql改写 => sql执行 => 结果归并 ，最终返回执行结果。
小结
垂直分表：将一张宽表(字段很多的表)，按照字段的访问频次进行拆分，就是按照表单结构进行 拆。
垂直分库：根据不同的业务，将表进行分类，拆分到不同的数据库。这些库可以部署在不同的服 务器，分摊访问压力。
水平分库：将一张表的数据 ( 按照数据行) 分到多个不同的数据库。每个库的表结构相同
水平分表：将一张表的数据 ( 按照数据行) ，分配到同一个数据库的多张表中，每个表都只有一部 分数据。
7sharding-jdbc实现读写分离
搭建mysql主从服务
根据上面docker配置mysql主从复制部分搭建。
主服务创建库表
create database sharding-jdbc-db;create table `t_user` ( `id` int(11) not null auto_increment, `nickname` varchar(100) default null, `password` varchar(100) default null, `sex` int(11) default null, `birthday` varchar(50) default null, primary key (`id`)) engine=innodb default charset=utf8mb4;
创建springboot工程，引入依赖
4.0.0 org.springframework.boot spring-boot-starter-parent 2.6.8 com.itjing springboot-sharding-jdbc 0.0.1-snapshot springboot-sharding-jdbc springboot-sharding-jdbc 1.8 org.springframework.boot spring-boot-starter-web org.projectlombok lombok true org.mybatis.spring.boot mybatis-spring-boot-starter 1.3.2 mysql mysql-connector-java 5.1.47 com.alibaba druid-spring-boot-starter 1.1.17 org.apache.shardingsphere sharding-jdbc-spring-boot-starter 4.0.0-rc1 org.springframework.boot spring-boot-starter-test test org.springframework.boot spring-boot-maven-plugin org.projectlombok lombok
配置文件
spring: main: allow-bean-definition-overriding: true shardingsphere: datasource: ds: maxpoolsize: 100 # master-ds1数据库连接信息 ds1: driver-class-name: com.mysql.jdbc.driver maxpoolsize: 100 minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3306/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # slave-ds2数据库连接信息 ds2: driver-class-name: com.mysql.jdbc.driver maxpoolsize: 100 minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3307/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # slave-ds3数据库连接信息 ds3: driver-class-name: com.mysql.jdbc.driver minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3307/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # 配置数据源 names: ds1,ds2,ds3 masterslave: # 配置slave节点的负载均衡均衡策略,采用轮询机制 load-balance-algorithm-type: round_robin # 配置主库master,负责数据的写入 master-data-source-name: ds1 # 配置主从名称 name: ms # 配置从库slave节点 slave-data-source-names: ds2,ds3 # 显示sql props: sql: show: true # 配置默认数据源ds1 默认数据源,主要用于写 sharding: default-data-source-name: ds1# 整合mybatis的配置mybatis: type-aliases-package: com.itjing.sharding.entity
定义controller、mapper、entity
package com.itjing.sharding.entity;import lombok.data;/** * @author lijing * @date 2022年06月19日 10:45 * @description */@datapublic class user { private integer id; private string nickname; private string password; private integer sex; private string birthday;}package com.itjing.sharding.controller;import com.itjing.sharding.entity.user;import com.itjing.sharding.mapper.usermapper;import org.springframework.beans.factory.annotation.autowired;import org.springframework.web.bind.annotation.getmapping;import org.springframework.web.bind.annotation.postmapping;import org.springframework.web.bind.annotation.requestmapping;import org.springframework.web.bind.annotation.restcontroller;import java.util.list;import java.util.random;/** * @author lijing * @date 2022年06月19日 10:45 * @description */@restcontroller@requestmapping(/api/user)public class usercontroller { @autowired private usermapper usermapper; @postmapping(/save) public string adduser() { user user = new user(); user.setnickname(zhangsan + new random().nextint()); user.setpassword(123456); user.setsex(1); user.setbirthday(1997-12-03); usermapper.adduser(user); return success; } @getmapping(/findusers) public list findusers() { return usermapper.findusers(); }}package com.itjing.sharding.mapper;import com.itjing.sharding.entity.user;import org.apache.ibatis.annotations.insert;import org.apache.ibatis.annotations.mapper;import org.apache.ibatis.annotations.select;import java.util.list;/** * @author lijing * @date 2022年06月19日 10:46 * @description */@mapperpublic interface usermapper { @insert(insert into t_user(nickname,password,sex,birthday) values(#{nickname},#{password},#{sex},#{birthday})) void adduser(user user); @select(select * from t_user) list findusers();}
启动项目验证
启动日志中三个数据源初始化成功：
调用http://localhost:8080/api/user/save一直进入到ds1主节点
调用http://localhost:8080/api/user/findusers一直进入到ds2、ds3节点，并且轮询进入
8sharding-jdbc实现分库分表
分表
创建库表
创建数据库及其对应的相同的两张表结构的表
先在mysql上创建数据库，直接起名叫做order
然后分别创建两个表，分别是order_1和order_2。
这两张表是订单表拆分后的表，通过sharding-jdbc向订单表插入数据，按照一定的分片规则，主键为偶数的落入order_1表 ，为奇数的落入order_2表，再通过sharding-jdbc 进行查询。
drop table if exists order_1;create table order_1 ( order_id bigint(20) primary key auto_increment , user_id int(11) , product_name varchar(128), count int(11));drop table if exists order_2;create table order_2 ( order_id bigint(20) primary key auto_increment , user_id int(11) , product_name varchar(128), count int(11));
创建springboot的项目
略
依赖
参照读写分离的依赖
配置文件
比较重要的一步，那就是配置分片规则，因为这里的分表是直接把数据进行水平拆分成到2个表中，所以属于水平切分数据表的操作，配置如下：
# 读写分离server: servlet: encoding: enabled: true charset: utf-8 force: truespring: application: name: sharding-jdbc-simple main: allow-bean-definition-overriding: true shardingsphere: datasource: names: db1 db1: type: com.alibaba.druid.pool.druiddatasource driver-class-name: com.mysql.jdbc.driver url: jdbc//127.0.0.1:3306/order?characterencoding=utf-8&usessl=false username: root password: root sharding: tables: order: actual-data-nodes: db1.order_$->{1..2} key-generator: column: order_id type: snowflake # 分表策略 table-strategy: inline: sharding-column: order_id algorithm-expression: order_$->{order_id % 2 + 1} props: sql: show: truemybatis: configuration: map-underscore-to-camel-case: true
测试
package com.itjing.sharding.mapper;import org.apache.ibatis.annotations.insert;import org.apache.ibatis.annotations.mapper;import org.apache.ibatis.annotations.param;/** * @author lijing * @date 2022年06月19日 11:18 * @description */@mapperpublic interface ordermapper { /** * 新增订单 */ @insert(insert into order(user_id,product_name,count) values(#{user_id},#{product_name},#{count})) int insertorder(@param(user_id) int user_id, @param(product_name) string product_name, @param(count) int count);}package com.itjing.sharding.controller;import com.itjing.sharding.mapper.ordermapper;import org.springframework.beans.factory.annotation.autowired;import org.springframework.web.bind.annotation.postmapping;import org.springframework.web.bind.annotation.requestmapping;import org.springframework.web.bind.annotation.restcontroller;/** * @author lijing * @date 2022年06月19日 11:20 * @description */@restcontroller@requestmapping(/api/order)public class ordercontroller { @autowired private ordermapper ordermapper; @postmapping(/save) public string testinsertorder() { for (int i = 0; i {1..2}.order_info key-generator: column: order_id type: snowflake # 分库策略 database-strategy: inline: sharding-column: user_id algorithm-expression: db$->{user_id % 2 + 1} props: sql: show: truemybatis: configuration: map-underscore-to-camel-case: true
配置文件，在这里是通过配置对数据库的分片策略，来指定数据库进行操作。
分库策略，以user_id为分片键，分片策略为user_id % 2 + 1，user_id为偶数操作db1数据源，否则操作db2。
这样的分库策略，直接通过 user_id 的奇偶性，来判断到底是用哪个数据源，用哪个数据库和表数据的。
测试
@insert(insert into order_info(user_id,product_name,count) values(#{user_id},#{product_name},#{count})) int insertorderfk(@param(user_id) int user_id, @param(product_name) string product_name, @param(count) int count);@postmapping(/savefk)public string savefk() { for (int i = 0; i {order_id % 2 + 1}，可以知道当 order_id 为偶数时，应该向 order_1表中插入数据，为奇数时向 order_2表插入数据。
结果归并：将所有真正执行sql的结果进行汇总合并，然后返回。
都知道，要是用sharding分库分表，那么自然就会有相对应的配置，而这些配置才是比较重要的地方，而其中比较经典的就是分片策略了。
分片策略
分片策略分为分表策略和分库策略，它们实现分片算法的方式基本相同，没有太大的区别，无非一个是针对库，一个是针对表。
而一般分片策略主要是分为如下的几种：
standard：标准分片策略
complex：复合分片策略
inline：行表达式分片策略，使用groovy的表达式.
hint：hint分片策略，对应hintshardingstrategy。
none：不分片策略，对应noneshardingstrategy。
标准分片策略standardshardingstrategy
使用场景：sql 语句中有>，>=, =，<=，<，=，in 和between and等操作符，不同的是复合分片策略支持对多个分片键操作。
这里要注意的就是多个分片键，也就是说，如果分片的话需要使用两个字段作为分片键，自定义复合分片策略。
行表达式分片策略
它的配置相当简洁，这种分片策略利用inline.algorithm-expression书写表达式。
这里就是使用的这个，来完成的分片，而且行表达式分片策略适用于做简单的分片算法，无需自定义分片算法，省去了繁琐的代码开发，是几种分片策略中最为简单的。
但是要注意，行表达式分片策略，它只支持单分片键。
hint分片策略
hint分片策略（hintshardingstrategy）和其他的分片策略都不一样了，这种分片策略无需配置分片键，分片键值也不再从 sql中解析，而是由外部指定分片信息，让 sql在指定的分库、分表中执行。
不分片策略
不分片策略这个没啥可说的，不分片的话，用sharing-jdbc的话，可能就没啥意思了。毕竟玩的就是分片。
官方文档：https://shardingsphere.apache.org/document/current/cn/overview/
视频分析处理器满足视频监控的储存需求
荣耀V9：清晰视界 快无止境 性价比已达极致！
选购空气净化器的三大要点
曝三星Galaxy S11+搭载一亿像素并支持100倍变焦 或一举超越市面上所有智能手机
利用Aqara来打造个性化全屋智能安防系统
SpringBoot + Sharding JDBC，一文搞定分库分表、读写分离
2019年DRAM市场供过于求，全球半导体营收下降12%
TE Connectivity发布2016年企业责任报告
小米又有新机？红米Note5曝光：骁龙652+4GB+安卓7.1
断相与相序继电器功能特点
RAB宣布2019年9月7日起灯具价格上涨10％
中频点焊机的变压器作用_中频点焊机变压器的维护
Api接口安全测试方法大全（附一键化扫描工具）
下一波移动机器人的主场就在这里！这家公司专利比亚马逊还多？
隧道气体检测系统：我们真的需要它吗?
广和通LTE Cat4模组L716焕新升级，为IoT行业提供经济普适无线应用
黑芝麻智能积极推进智能驾驶国产化
一文教你快速区分电力DTU和普通DTU
电液伺服阀的应用场景_电液伺服阀维修操作程序
LEM国产替代|霍尔开环电流传感器介绍
shardingsphere-jdbc定位为轻量级java框架，在java的jdbc层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，可理解为增强版的jdbc驱动，完全兼容jdbc和各种orm框架。
随着版本的不断更迭 shardingsphere 的核心功能也变得多元化起来。
从最开始 sharding-jdbc 1.0 版本只有数据分片，到 sharding-jdbc 2.0 版本开始支持数据库治理（注册中心、配置中心等等），再到 sharding-jdbc 3.0版本又加分布式事务 （支持 atomikos、narayana、bitronix、seata），如今已经迭代到了 sharding-jdbc 4.0 版本。
现在的 shardingsphere 不单单是指某个框架而是一个生态圈，这个生态圈sharding-jdbc、sharding-proxy和sharding-sidecar这三款开源的分布式数据库中间件解决方案所构成。
shardingsphere 的前身就是 sharding-jdbc，所以它是整个框架中最为经典、成熟的组件，先从 sharding-jdbc 框架入手学习分库分表。
1核心概念
分库分表
分库，显而易见，就是一个数据库分成多个数据库，部署到不同机器。
分表，就是一个数据库表分成多个表。
分片
一般在提到分库分表的时候，大多是以水平切分模式（水平分库、分表）为基础来说的，数据分片将原本一张数据量较大的表例如 t_order 拆分生成数个表结构完全一致的小数据量表 t_order_0、t_order_1、···、t_order_n，每张表只存储原大表中的一部分数据，当执行一条sql时会通过分库策略、分片策略将数据分散到不同的数据库、表内。
数据节点
数据节点是分库分表中一个不可再分的最小数据单元（表），它由数据源名称和数据表组成，例如上图中 order_db_1.t_order_0、order_db_2.t_order_1 就表示一个数据节点。
逻辑表
逻辑表是指一组具有相同逻辑和数据结构表的总称。
比如将订单表 t_order 拆分成 t_order_0 ··· t_order_9 等 10张表。
此时会发现分库分表以后数据库中已不在有 t_order 这张表，取而代之的是 t_order_n，但在代码中写 sql 依然按 t_order 来写。此时 t_order 就是这些拆分表的逻辑表。
真实表
真实表也就是上边提到的 t_order_n 数据库中真实存在的物理表。
分片键
用于分片的数据库字段。将 t_order 表分片以后，当执行一条sql时，通过对字段 order_id 取模的方式来决定，这条数据该在哪个数据库中的哪个表中执行，此时 order_id 字段就是 t_order 表的分片健。
这样以来同一个订单的相关数据就会存在同一个数据库表中，大幅提升数据检索的性能，不仅如此 sharding-jdbc 还支持根据多个字段作为分片健进行分片。
分片算法
上边提到可以用分片健取模的规则分片，但这只是比较简单的一种，在实际开发中还希望用 >=、、、=、， =，， =， {t_order_id % 4} 代表 t_order 对其字段 t_order_id取模，拆分成4张表，而表名分别是t_order_0 到 t_order_3。
4、hint分片策略
hint分片策略，对应上边的hint分片算法，通过指定分片健而非从 sql中提取分片健的方式进行分片的策略。
分布式主键
数据分⽚后，不同数据节点⽣成全局唯⼀主键是⾮常棘⼿的问题，同⼀个逻辑表（t_order）内的不同真实表（t_order_n）之间的⾃增键由于⽆法互相感知而产⽣重复主键。
尽管可通过设置⾃增主键 初始值 和 步⻓ 的⽅式避免id碰撞，但这样会使维护成本加大，乏完整性和可扩展性。如果后去需要增加分片表的数量，要逐一修改分片表的步长，运维成本非常高，所以不建议这种方式。
为了让上手更加简单，apacheshardingsphere 内置了uuid、snowflake 两种分布式主键⽣成器，默认使用雪花算法（snowflake）⽣成64bit的⻓整型数据。不仅如此它还抽离出分布式主键⽣成器的接口，方便实现自定义的自增主键生成算法。
广播表
广播表：存在于所有的分片数据源中的表，表结构和表中的数据在每个数据库中均完全一致。一般是为字典表或者配置表 t_config，某个表一旦被配置为广播表，只要修改某个数据库的广播表，所有数据源中广播表的数据都会跟着同步。
绑定表
绑定表：那些分片规则一致的主表和子表。比如：t_order 订单表和 t_order_item 订单服务项目表，都是按 order_id 字段分片，因此两张表互为绑定表关系。
那绑定表存在的意义是啥呢？
通常在业务中都会使用 t_order 和 t_order_item 等表进行多表联合查询，但由于分库分表以后这些表被拆分成n多个子表。如果不配置绑定表关系，会出现笛卡尔积关联查询，将产生如下四条sql。
select * from t_order_0 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_0 o join t_order_item_1 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_1 i on o.order_id=i.order_id
而配置绑定表关系后再进行关联查询时，只要对应表分片规则一致产生的数据就会落到同一个库中，那么只需 t_order_0 和 t_order_item_0 表关联即可。
select * from t_order_0 o join t_order_item_0 i on o.order_id=i.order_id select * from t_order_1 o join t_order_item_1 i on o.order_id=i.order_id
注意：在关联查询时 t_order 它作为整个联合查询的主表。所有相关的路由计算都只使用主表的策略，t_order_item 表的分片相关的计算也会使用 t_order 的条件，所以要保证绑定表之间的分片键要完全相同。
2mysql主从复制
docker配置mysql主从复制
创建主服务器所需目录
mkdir -p /usr/local/mysqldata/master/cnfmkdir -p /usr/local/mysqldata/master/data
定义主服务器配置文件
vim /usr/local/mysqldata/master/cnf/mysql.cnf[mysqld]## 设置server_id,注意要唯一server-id=1## 开启binloglog-bin=mysql-bin## binlog缓存binlog_cache_size=1m## binlog格式(mixed、statement、row,默认格式是statement)binlog_format=mixed
创建并启动mysql主服务
docker run -itd -p 3306:3306 --name master -v /usr/local/mysqldata/master/cnf:/etc/mysql/conf.d -v /usr/local/mysqldata/master/data:/var/lib/mysql -e mysql_root_password=123456 mysql:5.7
添加复制master数据的用户reader，供从服务器使用
[root@aliyun /]# docker pscontainer id image command created status ports names6af1df686fff mysql:5.7 docker-entrypoint... 5 seconds ago up 4 seconds 0.0.0.0:3306->3306/tcp, 33060/tcp master[root@aliyun /]# docker exec -it master /bin/bashroot@41d795785db1:/# mysql -u root -p123456mysql> grant replication slave on *.* to 'reader'@'%' identified by 'reader';query ok, 0 rows affected, 1 warning (0.00 sec)mysql> flush privileges;query ok, 0 rows affected (0.00 sec)
创建从服务器所需目录，编辑配置文件
mkdir /usr/local/mysqldata/slave/cnf -pmkdir /usr/local/mysqldata/slave/cnf -pvim /usr/local/mysqldata/slave/cnf/mysql.cnf[mysqld]## 设置server_id,注意要唯一server-id=2## 开启binlog,以备slave作为其它slave的master时使用log-bin=mysql-slave-bin## relay_log配置中继日志relay_log=edu-mysql-relay-bin## 如果需要同步函数或者存储过程log_bin_trust_function_creators=true## binlog缓存binlog_cache_size=1m## binlog格式(mixed、statement、row,默认格式是statement)binlog_format=mixed## 跳过主从复制中遇到的所有错误或指定类型的错误,避免slave端复制中断## 如:1062错误是指一些主键重复,1032错误是因为主从数据库数据不一致slave_skip_errors=1062
创建并运行mysql从服务器
docker run -itd -p 3307:3306 --name slaver -v /usr/local/mysqldata/slave/cnf:/etc/mysql/conf.d -v /usr/local/mysqldata/slave/data:/var/lib/mysql -e mysql_root_password=123456 mysql:5.7
在从服务器上配置连接主服务器的信息
首先主服务器上查看master_log_file、master_log_pos两个参数，然后切换到从服务器上进行主服务器的连接信息的设置
主服务上执行：
root@6af1df686fff:/# mysql -u root -p123456mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| file | position | binlog_do_db | binlog_ignore_db | executed_gtid_set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 591 | | | |+------------------+----------+--------------+------------------+-------------------+1 row in set (0.00 sec)
docker查看主服务器容器的ip地址
[root@aliyun /]# docker inspect --format='{{.networksettings.ipaddress}}' master172.17.0.2
从服务器上执行：
[root@aliyun /]# docker exec -it slaver /bin/bashroot@fe8b6fc2f1ca:/# mysql -u root -p123456 mysql> change master to master_host='172.17.0.2',master_user='reader',master_password='reader',master_log_file='mysql-bin.000003',master_log_pos=591;
从服务器启动i/o 线程和sql线程
mysql> start slave;query ok, 0 rows affected, 1 warning (0.00 sec)mysql> show slave statusg*************************** 1. row *************************** slave_io_state: waiting for master to send event master_host: 172.17.0.2 master_user: reader master_port: 3306 connect_retry: 60 master_log_file: mysql-bin.000003 read_master_log_pos: 591 relay_log_file: edu-mysql-relay-bin.000002 relay_log_pos: 320 relay_master_log_file: mysql-bin.000003 slave_io_running: yes slave_sql_running: yes
slave_io_running: yes，slave_sql_running: yes 即表示启动成功
binlog和redo log回顾
redo log（重做日志）
innodb首先将redo log放入到redo log buffer，然后按一定频率将其刷新到redo log file
下列三种情况下会将redo log buffer刷新到redo log file：
master thread每一秒将redo log buffer刷新到redo log file
每个事务提交时会将redo log buffer刷新到redo log file
当redo log缓冲池剩余空间小于1/2时，会将redo log buffer刷新到redo log file
mysql里常说的wal技术，全称是write ahead log，即当事务提交时，先写redo log，再修改页。也就是说，当有一条记录需要更新的时候，innodb会先把记录写到redo log里面，并更新buffer pool的page，这个时候更新操作就算完成了
buffer pool是物理页的缓存，对innodb的任何修改操作都会首先在buffer pool的page上进行，然后这样的页将被标记为脏页并被放到专门的flush list上，后续将由专门的刷脏线程阶段性的将这些页面写入磁盘
innodb的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1gb，循环使用，从头开始写，写到末尾就又回到开头循环写（顺序写，节省了随机写磁盘的io消耗）
write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。check point是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件
write pos和check point之间空着的部分，可以用来记录新的操作。如果write pos追上check point，这时候不能再执行新的更新，需要停下来擦掉一些记录，把check point推进一下
当数据库发生宕机时，数据库不需要重做所有的日志，因为check point之前的页都已经刷新回磁盘，只需对check point后的redo log进行恢复，从而缩短了恢复的时间
当缓冲池不够用时，根据lru算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行check point，将脏页刷新回磁盘
binlog（归档日志）
mysql整体来看就有两块：一块是server层，主要做的是mysql功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。redo log是innodb引擎特有的日志，而server层也有自己的日志，称为binlog
binlog记录了对mysql数据库执行更改的所有操作，不包括select和show这类操作，主要作用是用于数据库的主从复制及数据的增量恢复
使用mysqldump备份时，只是对一段时间的数据进行全备，但是如果备份后突然发现数据库服务器故障，这个时候就要用到binlog的日志了
binlog格式有三种：statement，row，mixed
statement模式：binlog里面记录的就是sql语句的原文。优点是并不需要记录每一行的数据变化，减少了binlog日志量，节约io，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致
row模式：不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了，解决了statement模式下出现master-slave中的数据不一致。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨
mixed模式：以上两种模式的混合使用，一般的复制使用statement模式保存binlog，对于statement模式无法复制的操作使用row模式保存binlog，mysql会根据执行的sql语句选择日志保存方式
redo log和binlog日志的不同
redo log是innodb引擎特有的；binlog是mysql的server层实现的，所有引擎都可以使用
redo log是物理日志，记录的是在某个数据也上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给id=2这一行的c字段加1
redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志
两阶段提交
create table t(id int primary key, c int);update t set c=c+1 where id=2;
执行器和innodb引擎在执行这个update语句时的内部流程：
执行器先找到引擎取id=2这一行。id是主键，引擎直接用树搜索找到这一行。如果id=2这一行所在的数据也本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回
执行器拿到引擎给的行数据，把这个值加上1，得到新的一行数据，再调用引擎接口写入这行新数据
引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务
执行器生成这个操作的binlog，并把binlog写入磁盘
执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交状态，更新完成
update语句的执行流程图如下，图中浅色框表示在innodb内部执行的，深色框表示是在执行器中执行的
将redo log的写入拆成了两个步骤：prepare和commit，这就是两阶段提交
mysql主从复制原理
从库b和主库a之间维持了一个长连接。主库a内部有一个线程，专门用于服务从库b的这个长连接。一个事务日志同步的完整过程如下：
在从库b上通过change master命令，设置主库a的ip、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量
在从库b上执行start slave命令，这时从库会启动两个线程，就是图中的i/o线程和sql线程。其中i/o线程负责与主库建立连接
主库a校验完用户名、密码后，开始按照从库b传过来的位置，从本地读取binlog，发给b
从库b拿到binlog后，写到本地文件，称为中继日志
sql线程读取中继日志，解析出日志里的命令，并执行
由于多线程复制方案的引入，sql线程演化成了多个线程。
主从复制不是完全实时地进行同步，而是异步实时。这中间存在主从服务之间的执行延时，如果主服务器的压力很大，则可能导致主从服务器延时较大。
3为什么需要分库分表？
首先要明确一个问题，单一的数据库是否能够满足公司目前的线上业务需求，比如用户表，可能有几千万，甚至上亿的数据，只是说可能，如果有这么多用户，那必然是大公司了，那么这个时候，如果不分表也不分库的话，那么数据了上来的时候，稍微一个不注意，mysql单机磁盘容量会撑爆，但是如果拆成多个数据库，磁盘使用率大大降低。
这样就把磁盘使用率降低，这是通过硬件的形式解决问题，如果数据量是巨大的，这时候，sql 如果没有命中索引，那么就会导致一个情况，查这个表的sql语句直接把数据库给干崩了。
即使sql命中了索引，如果表的数据量 超过一千万的话， 查询也是会明显变慢的。这是因为索引一般是b+树结构，数据千万级别的话，b+树的高度会增高，查询自然就变慢了，当然，这是题外话了。
4mysql分库分表原理
分库分表
水平拆分：同一个表的数据拆到不同的库不同的表中。可以根据时间、地区或某个业务键维度，也可以通过hash进行拆分，最后通过路由访问到具体的数据。拆分后的每个表结构保持一致
垂直拆分：就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，可以根据业务维度进行拆分，如订单表可以拆分为订单、订单支持、订单地址、订单商品、订单扩展等表；也可以，根据数据冷热程度拆分，20%的热点字段拆到一个表，80%的冷字段拆到另外一个表
不停机分库分表数据迁移
一般数据库的拆分也是有一个过程的，一开始是单表，后面慢慢拆成多表。那么就看下如何平滑的从mysql单表过度到mysql的分库分表架构
利用mysql+canal做增量数据同步，利用分库分表中间件，将数据路由到对应的新表中
利用分库分表中间件，全量数据导入到对应的新表中
通过单表数据和分库分表数据两两比较，更新不匹配的数据到新表中
数据稳定后，将单表的配置切换到分库分表配置上
5分库分表方案
分库分表方案，不外乎就两种，一种是垂直切分，一种是水平切分。
但是总有做开发的小伙伴不知道这垂直切分和水平切分到底是什么样的，为什么垂直切分，为什么水平切分，什么时候应该选择垂直切分，什么时候应该选择水平切分。
有人是这么说的，垂直切分是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。
有些人不理解这个，实际上垂直切分也是有划分的，上面描述的是垂直切分数据库，可能容易让很多人不太理解，但是如果是垂直切分表，那么肯定百分之90的人都能理解。
垂直切分
有一张order表，表中有诸多记录，比如设计这么一张简单的表。
id order_id order_date order_type order_state
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311 支付宝 1
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433 微信 2
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544 现金 2
以上是简化版order表，如果想要垂直切分，那么应该怎么处理？
直接拆分成2个表，这时候就直接就一分为2 ，咔的一下拆分成两个表
order1
id order_id order_date
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544
order2
id order_type order_state
1 支付宝 1
2 微信 2
3 现金 2
这时候主键id保持的时一致的，而这个操作，就是垂直拆分，分表的操作。
既然说了垂直拆分，那么必然就有水平拆分，
什么是水平拆分呢？
实际上水平拆分的话，那真的是只有一句话。
水平切分
按照数据来拆分
水平拆分数据库：将一张表的数据 ( 按照数据行) 分到多个不同的数据库。每个库的表结构相同，每个库都只有这张表的部分数据，当单表的数据量过大，如果继续使用水平分库，那么数据库的实例 就会不断增加，不利于系统的运维。这时候就要采用水平分表。
水平拆分表：将一张表的数据 ( 按照数据行) ，分配到同一个数据库的多张表中，每个表都只有一部分数据。
来看看order表进行水平拆分的话，是什么样子的。
order1
id order_id order_date order_type order_state
1 cd96cff0356e483caae6b2ff4e878fd6 2022-06-18 1311 支付宝 1
2 e2496f9e22ce4391806b18480440526a 2022-06-18 1433 微信 2
order2
id order_id order_date order_type order_state
3 9e7ab5a1915c4570a9eaaaa3c01f79c1 2022-06-18 1544 现金 2
实际上就是水平的把表数据给分成了2份，这么看起来是不是就很好理解了。
6分库分表带来的问题
事务问题
首先，分库分表最大的隐患就是，事务的一致性， 当需要更新的内容同时分布在不同的库时，不可避免的会产生跨库的事务问题。
原来在一个数据库操 作，本地事务就可以进行控制，分库之后 一个请求可能要访问多个数据库，如何保证事务的一致性，目前还没有简单的解决方案。
无法联表的问题
还有一个就是，没有办法进行联表查询了，因为，原来在一个库中的一些表，被分散到多个库，并且这些数据库可能还不在一台服务器，无法关联查询，所以相对应的业务代码可能就比较多了。
分页问题
分库并行查询时，如果用到了分页，每个库返回的结果集本身是无序的，只有将多个库中的数据先查出来，然后再根据排序字段在内存中进行排序，如果查询结果过大也是十分消耗资源的。
分库分表的技术
目前比较流行的就两种，一种是mycat，另外一种则是sharding-jdbc，都是可以进行分库的，
mycat是一个数据库中间件，sharding-jdbc是以 jar 包提供服务的jdbc框架。
mycat和sharding-jdbc 实现原理也是不同：
mycat的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的sql语句，首先对sql语句做了一些特定的分析：如分库分表分析、路由分析、读写分离分析、缓存分析等，然后将此sql发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
而sharding-jdbc的原理是接受到一条sql语句时，会陆续执行sql解析 => 查询优化 => sql路由 => sql改写 => sql执行 => 结果归并 ，最终返回执行结果。
小结
垂直分表：将一张宽表(字段很多的表)，按照字段的访问频次进行拆分，就是按照表单结构进行 拆。
垂直分库：根据不同的业务，将表进行分类，拆分到不同的数据库。这些库可以部署在不同的服 务器，分摊访问压力。
水平分库：将一张表的数据 ( 按照数据行) 分到多个不同的数据库。每个库的表结构相同
水平分表：将一张表的数据 ( 按照数据行) ，分配到同一个数据库的多张表中，每个表都只有一部 分数据。
7sharding-jdbc实现读写分离
搭建mysql主从服务
根据上面docker配置mysql主从复制部分搭建。
主服务创建库表
create database sharding-jdbc-db;create table `t_user` ( `id` int(11) not null auto_increment, `nickname` varchar(100) default null, `password` varchar(100) default null, `sex` int(11) default null, `birthday` varchar(50) default null, primary key (`id`)) engine=innodb default charset=utf8mb4;
创建springboot工程，引入依赖
4.0.0 org.springframework.boot spring-boot-starter-parent 2.6.8 com.itjing springboot-sharding-jdbc 0.0.1-snapshot springboot-sharding-jdbc springboot-sharding-jdbc 1.8 org.springframework.boot spring-boot-starter-web org.projectlombok lombok true org.mybatis.spring.boot mybatis-spring-boot-starter 1.3.2 mysql mysql-connector-java 5.1.47 com.alibaba druid-spring-boot-starter 1.1.17 org.apache.shardingsphere sharding-jdbc-spring-boot-starter 4.0.0-rc1 org.springframework.boot spring-boot-starter-test test org.springframework.boot spring-boot-maven-plugin org.projectlombok lombok
配置文件
spring: main: allow-bean-definition-overriding: true shardingsphere: datasource: ds: maxpoolsize: 100 # master-ds1数据库连接信息 ds1: driver-class-name: com.mysql.jdbc.driver maxpoolsize: 100 minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3306/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # slave-ds2数据库连接信息 ds2: driver-class-name: com.mysql.jdbc.driver maxpoolsize: 100 minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3307/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # slave-ds3数据库连接信息 ds3: driver-class-name: com.mysql.jdbc.driver minpoolsize: 5 password: 123456 type: com.alibaba.druid.pool.druiddatasource url: jdbc//192.168.56.111:3307/sharding-jdbc-db?useunicode=true&usessl=false&servertimezone=asia/shanghai username: root # 配置数据源 names: ds1,ds2,ds3 masterslave: # 配置slave节点的负载均衡均衡策略,采用轮询机制 load-balance-algorithm-type: round_robin # 配置主库master,负责数据的写入 master-data-source-name: ds1 # 配置主从名称 name: ms # 配置从库slave节点 slave-data-source-names: ds2,ds3 # 显示sql props: sql: show: true # 配置默认数据源ds1 默认数据源,主要用于写 sharding: default-data-source-name: ds1# 整合mybatis的配置mybatis: type-aliases-package: com.itjing.sharding.entity
定义controller、mapper、entity
package com.itjing.sharding.entity;import lombok.data;/** * @author lijing * @date 2022年06月19日 10:45 * @description */@datapublic class user { private integer id; private string nickname; private string password; private integer sex; private string birthday;}package com.itjing.sharding.controller;import com.itjing.sharding.entity.user;import com.itjing.sharding.mapper.usermapper;import org.springframework.beans.factory.annotation.autowired;import org.springframework.web.bind.annotation.getmapping;import org.springframework.web.bind.annotation.postmapping;import org.springframework.web.bind.annotation.requestmapping;import org.springframework.web.bind.annotation.restcontroller;import java.util.list;import java.util.random;/** * @author lijing * @date 2022年06月19日 10:45 * @description */@restcontroller@requestmapping(/api/user)public class usercontroller { @autowired private usermapper usermapper; @postmapping(/save) public string adduser() { user user = new user(); user.setnickname(zhangsan + new random().nextint()); user.setpassword(123456); user.setsex(1); user.setbirthday(1997-12-03); usermapper.adduser(user); return success; } @getmapping(/findusers) public list findusers() { return usermapper.findusers(); }}package com.itjing.sharding.mapper;import com.itjing.sharding.entity.user;import org.apache.ibatis.annotations.insert;import org.apache.ibatis.annotations.mapper;import org.apache.ibatis.annotations.select;import java.util.list;/** * @author lijing * @date 2022年06月19日 10:46 * @description */@mapperpublic interface usermapper { @insert(insert into t_user(nickname,password,sex,birthday) values(#{nickname},#{password},#{sex},#{birthday})) void adduser(user user); @select(select * from t_user) list findusers();}
启动项目验证
启动日志中三个数据源初始化成功：
调用http://localhost:8080/api/user/save一直进入到ds1主节点
调用http://localhost:8080/api/user/findusers一直进入到ds2、ds3节点，并且轮询进入
8sharding-jdbc实现分库分表
分表
创建库表
创建数据库及其对应的相同的两张表结构的表
先在mysql上创建数据库，直接起名叫做order
然后分别创建两个表，分别是order_1和order_2。
这两张表是订单表拆分后的表，通过sharding-jdbc向订单表插入数据，按照一定的分片规则，主键为偶数的落入order_1表 ，为奇数的落入order_2表，再通过sharding-jdbc 进行查询。
drop table if exists order_1;create table order_1 ( order_id bigint(20) primary key auto_increment , user_id int(11) , product_name varchar(128), count int(11));drop table if exists order_2;create table order_2 ( order_id bigint(20) primary key auto_increment , user_id int(11) , product_name varchar(128), count int(11));
创建springboot的项目
略
依赖
参照读写分离的依赖
配置文件
比较重要的一步，那就是配置分片规则，因为这里的分表是直接把数据进行水平拆分成到2个表中，所以属于水平切分数据表的操作，配置如下：
# 读写分离server: servlet: encoding: enabled: true charset: utf-8 force: truespring: application: name: sharding-jdbc-simple main: allow-bean-definition-overriding: true shardingsphere: datasource: names: db1 db1: type: com.alibaba.druid.pool.druiddatasource driver-class-name: com.mysql.jdbc.driver url: jdbc//127.0.0.1:3306/order?characterencoding=utf-8&usessl=false username: root password: root sharding: tables: order: actual-data-nodes: db1.order_$->{1..2} key-generator: column: order_id type: snowflake # 分表策略 table-strategy: inline: sharding-column: order_id algorithm-expression: order_$->{order_id % 2 + 1} props: sql: show: truemybatis: configuration: map-underscore-to-camel-case: true
测试
package com.itjing.sharding.mapper;import org.apache.ibatis.annotations.insert;import org.apache.ibatis.annotations.mapper;import org.apache.ibatis.annotations.param;/** * @author lijing * @date 2022年06月19日 11:18 * @description */@mapperpublic interface ordermapper { /** * 新增订单 */ @insert(insert into order(user_id,product_name,count) values(#{user_id},#{product_name},#{count})) int insertorder(@param(user_id) int user_id, @param(product_name) string product_name, @param(count) int count);}package com.itjing.sharding.controller;import com.itjing.sharding.mapper.ordermapper;import org.springframework.beans.factory.annotation.autowired;import org.springframework.web.bind.annotation.postmapping;import org.springframework.web.bind.annotation.requestmapping;import org.springframework.web.bind.annotation.restcontroller;/** * @author lijing * @date 2022年06月19日 11:20 * @description */@restcontroller@requestmapping(/api/order)public class ordercontroller { @autowired private ordermapper ordermapper; @postmapping(/save) public string testinsertorder() { for (int i = 0; i {1..2}.order_info key-generator: column: order_id type: snowflake # 分库策略 database-strategy: inline: sharding-column: user_id algorithm-expression: db$->{user_id % 2 + 1} props: sql: show: truemybatis: configuration: map-underscore-to-camel-case: true
配置文件，在这里是通过配置对数据库的分片策略，来指定数据库进行操作。
分库策略，以user_id为分片键，分片策略为user_id % 2 + 1，user_id为偶数操作db1数据源，否则操作db2。
这样的分库策略，直接通过 user_id 的奇偶性，来判断到底是用哪个数据源，用哪个数据库和表数据的。
测试
@insert(insert into order_info(user_id,product_name,count) values(#{user_id},#{product_name},#{count})) int insertorderfk(@param(user_id) int user_id, @param(product_name) string product_name, @param(count) int count);@postmapping(/savefk)public string savefk() { for (int i = 0; i {order_id % 2 + 1}，可以知道当 order_id 为偶数时，应该向 order_1表中插入数据，为奇数时向 order_2表插入数据。
结果归并：将所有真正执行sql的结果进行汇总合并，然后返回。
都知道，要是用sharding分库分表，那么自然就会有相对应的配置，而这些配置才是比较重要的地方，而其中比较经典的就是分片策略了。
分片策略
分片策略分为分表策略和分库策略，它们实现分片算法的方式基本相同，没有太大的区别，无非一个是针对库，一个是针对表。
而一般分片策略主要是分为如下的几种：
standard：标准分片策略
complex：复合分片策略
inline：行表达式分片策略，使用groovy的表达式.
hint：hint分片策略，对应hintshardingstrategy。
none：不分片策略，对应noneshardingstrategy。
标准分片策略standardshardingstrategy
使用场景：sql 语句中有>，>=, =，<=，<，=，in 和between and等操作符，不同的是复合分片策略支持对多个分片键操作。
这里要注意的就是多个分片键，也就是说，如果分片的话需要使用两个字段作为分片键，自定义复合分片策略。
行表达式分片策略
它的配置相当简洁，这种分片策略利用inline.algorithm-expression书写表达式。
这里就是使用的这个，来完成的分片，而且行表达式分片策略适用于做简单的分片算法，无需自定义分片算法，省去了繁琐的代码开发，是几种分片策略中最为简单的。
但是要注意，行表达式分片策略，它只支持单分片键。
hint分片策略
hint分片策略（hintshardingstrategy）和其他的分片策略都不一样了，这种分片策略无需配置分片键，分片键值也不再从 sql中解析，而是由外部指定分片信息，让 sql在指定的分库、分表中执行。
不分片策略
不分片策略这个没啥可说的，不分片的话，用sharing-jdbc的话，可能就没啥意思了。毕竟玩的就是分片。
官方文档：https://shardingsphere.apache.org/document/current/cn/overview/
视频分析处理器满足视频监控的储存需求
荣耀V9：清晰视界 快无止境 性价比已达极致！
选购空气净化器的三大要点
曝三星Galaxy S11+搭载一亿像素并支持100倍变焦 或一举超越市面上所有智能手机
利用Aqara来打造个性化全屋智能安防系统
SpringBoot + Sharding JDBC，一文搞定分库分表、读写分离
2019年DRAM市场供过于求，全球半导体营收下降12%
TE Connectivity发布2016年企业责任报告
小米又有新机？红米Note5曝光：骁龙652+4GB+安卓7.1
断相与相序继电器功能特点
RAB宣布2019年9月7日起灯具价格上涨10％
中频点焊机的变压器作用_中频点焊机变压器的维护
Api接口安全测试方法大全（附一键化扫描工具）
下一波移动机器人的主场就在这里！这家公司专利比亚马逊还多？
隧道气体检测系统：我们真的需要它吗?
广和通LTE Cat4模组L716焕新升级，为IoT行业提供经济普适无线应用
黑芝麻智能积极推进智能驾驶国产化
一文教你快速区分电力DTU和普通DTU
电液伺服阀的应用场景_电液伺服阀维修操作程序
LEM国产替代|霍尔开环电流传感器介绍