ShardingSphere数据库中间件
一、SharingJdbc简介
1、概述
官网:http://shardingsphere.apache.org/index_zh.html
官网概述:https://shardingsphere.apache.org/document/current/cn/overview/
Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈,它由 JDBC、Proxy 和 Sidecar(规划中)这 3 款既能够独立部署,又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能,可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
2、Sharding-Jdbc介绍
shardingjdbc定位为轻量级 Java 框架,在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库,以 jar 包形式提供服务,无需额外部署和依赖,可理解为增强版的 JDBC 驱动,完全兼容 JDBC 和各种 ORM 框架。
- 适用于任何基于 JDBC 的 ORM 框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
- 支持任何第三方的数据库连接池,如:DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 支持任意实现 JDBC 规范的数据库,目前支持 MySQL,Oracle,SQLServer,PostgreSQL 以及任何遵循 SQL92 标准的数据库。
3、Sharding-Proxy介绍
定位为透明化的数据库代理端,提供封装了数据库二进制协议的服务端版本,用于完成对异构语言的支持。
4、ShardingSphere-Sidecar(TODO)
5、三种组件对比
ShardingSphere-JDBC | ShardingSphere-Proxy | ShardingSphere-Sidecar | |
---|---|---|---|
数据库 | 任意 | MySQL/PostgreSQL | MySQL/PostgreSQL |
连接消耗数 | 高 | 低 | 高 |
异构语言 | 仅 Java | 任意 | 任意 |
性能 | 损耗低 | 损耗略高 | 损耗低 |
无中心化 | 是 | 否 | 是 |
静态入口 | 无 | 有 | 无 |
6、ShardingJdbc混合架构
ShardingSphere-JDBC 采用无中心化架构,适用于 Java 开发的高性能的轻量级 OLTP(连接事务处理) 应用;ShardingSphere-Proxy 提供静态入口以及异构语言的支持,适用于 OLAP(连接数据分析) 应用以及对分片数据库进行管理和运维的场景。
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy,并采用同一注册中心统一配置分片策略,能够灵活的搭建适用于各种场景的应用系统,使得架构师更加自由地调整适合与当前业务的最佳系统架构。
7、功能列表
数据分片
- 分库 & 分表
- 读写分离
- 分片策略定制化
- 无中心化分布式主键
分布式事务
- 标准化事务接口
- XA 强一致事务
- 柔性事务
数据库治理
- 分布式治理
- 弹性伸缩
- 可视化链路追踪
- 数据加密
8、ShardingSphere数据分片内核剖析
ShardingSphere 的 3 个产品的数据分片主要流程是完全一致的。 核心由 SQL 解析 => 执行器优化 => SQL 路由 => SQL 改写 => SQL 执行 => 结果归并的流程组成。
SQL 解析
分为词法解析和语法解析。 先通过词法解析器将 SQL 拆分为一个个不可再分的单词。再使用语法解析器对 SQL 进行理解,并最终提炼出解析上下文。 解析上下文包括表、选择项、排序项、分组项、聚合函数、分页信息、查询条件以及可能需要修改的占位符的标记。
执行器优化
合并和优化分片条件,如 OR 等。
SQL 路由
根据解析上下文匹配用户配置的分片策略,并生成路由路径。目前支持分片路由和广播路由。
SQL 改写
将 SQL 改写为在真实数据库中可以正确执行的语句。SQL 改写分为正确性改写和优化改写。
SQL 执行
通过多线程执行器异步执行。
结果归并
将多个执行结果集归并以便于通过统一的 JDBC 接口输出。结果归并包括流式归并、内存归并和使用装饰者模式的追加归并这几种方式。
二、MySql主从复制
1、概述
主从复制(也称 AB 复制)允许将来自一个MySQL数据库服务器(主服务器)的数据复制到一个或多个MySQL数据库服务器(从服务器)。其中复制是异步的 从站不需要永久连接以接收来自主站的更新。
优点
- 横向扩展解决方案 - 在多个从站之间分配负载以提高性能。在此环境中,所有写入和更新都必须在主服务器上进行。但是,读取可以在一个或多个从设备上进行。该模型可以提高写入性能(因为主设备专用于更新),同时显着提高了越来越多的从设备的读取速度。
- 数据安全性 - 因为数据被复制到从站,并且从站可以暂停复制过程,所以可以在从站上运行备份服务而不会破坏相应的主数据。
- 分析 - 可以在主服务器上创建实时数据,而信息分析可以在从服务器上进行,而不会影响主服务器的性能。
- 远程数据分发 - 您可以使用复制为远程站点创建数据的本地副本,而无需永久访问主服务器。
对于Mysql环境,本次系统使用了Centos8,Mysql版本为8.0
2、主从复制原理
主服务器上面的任何修改都会通过自己的 I/O tread(I/O 线程)保存在二进制日志 Binary log 里面。
- 从服务器上面也启动一个 I/O thread,通过配置好的用户名和密码, 连接到主服务器上面请求读取二进制日志,然后把读取到的二进制日志写到本地的一个Realy log(中继日志)里面。
- 从服务器上面同时开启一个 SQL thread 定时检查 Realy log(这个文件也是二进制的),如果发现有更新立即把更新的内容在本机的数据库上面执行一遍。
每个从服务器都会收到主服务器二进制日志的全部内容的副本。 - 从服务器设备负责决定应该执行二进制日志中的哪些语句。
除非另行指定,否则主从二进制日志中的所有事件都在从站上执行。
如果需要,您可以将从服务器配置为仅处理一些特定数据库或表的事件。
注:作为主服务器角色的数据库服务器必须开启二进制日志
3、Mysql配置
1、Master节点配置/etc/my.cnf
(master节点执行)
1 | > vim /etc/my.cnf |
2、Slave节点配置/etc/my.cnf
(slave节点执行)
1 | > vim /etc/my.cnf |
3、在master服务器授权slave服务器可以同步权限(master节点执行)
1 | # 在Master上执行 |
4、查询master服务的binlog文件名和位置(master节点执行)
1 | show master status; |
5、slave进行关联master节点(slave节点执行)
1 | mysql -uroot -p(slave的密码) |
在主从复制操作的时候,不要基于去创建数据库或者相关操作,然后又去删除。若这样可能需要重新绑定主机位置
4、常见错误排查
1、Host ‘xxxx’ is not allowed to connect to this MySQL server
发生该问题一般是想远程连接root权限的数据库,这需要修改修改mysql权限表 。
1 | ##进入root权限的数据库后查看当前权限 |
2、主从复制Connecting问题
使用start slave
开启主从复制过程后,如果SlaveIORunning一直是Connecting,则说明主从复制一直处于连接状态,这种情况一般是下面几种原因造成的,我们可以根据 Last_IO_Error提示予以排除。
- 网络不通
- 检查ip,端口
- 密码不对
- 检查是否创建用于同步的用户和用户密码是否正确
- pos不对
- 检查Master的 Position
3、MYSQL镜像服务器因错误停止的恢复 Slave_SQL_Running: No
1 | stop slave; |
4、从MYSQL服务器Slave_IO_Running: No
造成这类问题的原因一般是在主从复制的时候,基于创建表,然后又去删除和操作了数据表或者表。
- master节点执行,获取日志文件和post
1 | show master status; |
- slave节点进行重新绑定
1 | stop slave; |
三、SharingJdbc配置和读写分离
1、数据库数据准备
2、实现步骤
1、新建一个springboot工程
2、引入相关sharding依赖、ssm依赖、数据库驱动
1 | <properties> |
3、定义配置application.yml
1 | server: |
4、 定义mapper、controller、entity
entity
1 |
|
mapper
1 |
|
controller
1 |
|
5、Props其他参数配置
1 | acceptor.size: # accept连接的线程数量,默认为cpu核数2倍 |
四、SharingJdbc分库和分表
1、Mysql分库分表原理
1、概述
分库分表目的:解决高并发,和数据量大的问题。
1、高并发情况下,会造成IO读写频繁,自然就会造成读写缓慢,甚至是宕机。一般单库不要超过2k并发,一个表数据建议不要超过500W。
2、数据量大的问题。主要由于底层索引实现导致,MySQL的索引实现为B+TREE,数据量其他,会导致索引树十分庞大,造成查询缓慢。第二,innodb的最大存储限制64TB。
2、分库分表
分库分表又分为水平拆分和垂直拆分
**水平拆分:**统一个表的数据拆到不同的库不同的表中。可以根据时间、地区、或某个业务键维度,也可以通过hash进行拆分,最后通过路由访问到具体的数据。拆分后的每个表结构保持一致。
**垂直拆分:**就是把一个有很多字段的表给拆分成多个表,或者是多个库上去。每个库表的结构都不一样,每个库表都包含部分字段。一般来说,可以根据业务维度进行拆分,如订单表可以拆分为订单、订单支持、订单地址、订单商品、订单扩展等表;也可以,根据数据冷热程度拆分,20%的热点字段拆到一个表,80%的冷字段拆到另外一个表(拆分两个表建立1:1关系)。
对于数据同步,有全量数据同步(主从复制)和增量数据同步(Canal)两种
2、实现步骤
数据库复制了shawn_order_db
表变成shawn_order_db0
和shawn_order_db1
,对于yml配置文件
。配置成功后分库分表、单库分表等操作可以自定义实现。
1 | server: |
3、其他分片算法策略(了解)
- 标准分片 - Standard
- 符合分片策略
- hint分片策略
五、分布式主键管理
1、分布式ID
ShardingSphere提供灵活的配置分布式主键生成策略方式。在分片规则配置模块克配置每个表的主键生成策略。默认使用雪花算法。(snowflake)生成64bit的长整型数据。支持两种方式配置
- SNOWFLAKE
- UUID
切记:如果用雪花算法,数据库主键列不能自增长。数据类型是:bigint(20),在java类中使用long类型,不要用String类型;
如果用UUID,数据库用varchar,Java类用String,推荐用雪花,性能好
mapper修改
1 | //这样能返回id值,直接控制台输出可以看见,这是Mybatis注解 |
yaml配置文件修改
1 | #在配置文件相应位置添加 |
2、Mysql日期实战
按照年月分库分表,比如shawn_user_order_202101、shawn_user_order_202102,这样可以方便按照月份划分表,在运行前需要在数据库先创建好表。
下面配置仅供参考
策略类
1 | public class YearMonthShardingAlgorithm implements PreciseShardingAlgorithm<String> { |
配置类,数据源和之前一样
1 | spring: |
六、SharingJdbc事务管理
1、事务概述
数据库事务需要满足ACID(原子性、一致性、隔离性、持久性)四个特性。
- 原子性(Atomicity)指事务作为整体来执行,要么全部执行,要么全不执行。
- 一致性(Consistency)指事务应确保数据从一个一致的状态转变为另一个一致的状态。
- 隔离性(Isolation)指多个事务并发执行时,一个事务的执行不应影响其他事务的执行。
- 持久性(Durability)指已提交的事务修改数据会被持久保存
两阶段提交
XA协议最早的分布式事务模型是由X/Open国际联盟提出的X/Open Distributed Transaction Processing(DTP)模型,简称XA协议。
基于XA协议实现的分布式事务对业务侵入很小。 它最大的优势就是对使用方透明,用户可以像使用本地事务一样使用基于XA协议的分布式事务。 XA协议能够严格保障事务ACID特性。严格保障事务ACID特性是一把双刃剑。 事务执行在过程中需要将所需资源全部锁定,它更加适用于执行时间确定的短事务。 对于长事务来说,整个事务进行期间对数据的独占,将导致对热点数据依赖的业务系统并发性能衰退明显。 因此,在高并发的性能至上场景中,基于XA协议的分布式事务并不是最佳选择。
柔性事务
如果将实现了ACID的事务要素的事务称为刚性事务的话,那么基于BASE事务要素的事务则称为柔性事务。 BASE是基本可用、柔性状态和最终一致性这三个要素的缩写。
基本可用(Basically Available)保证分布式事务参与方不一定同时在线。柔性状态(Soft state)则允许系统状态更新有一定的延时,这个延时对客户来说不一定能够察觉。而最终一致性(Eventually consistent)通常是通过消息传递的方式保证系统的最终一致性。
在ACID事务中对隔离性的要求很高,在事务执行过程中,必须将所有的资源锁定。 柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求,来换取系统吞吐量的提升。
2、简单实现步骤
添加依赖
1 | <!--依赖sharding--> |
在service层添加注解
1 |
|
七、MySql常用规范
基础规范
- 表必须有主键,建议使用整型作为主键
- 禁止使用外键,表之间的关联性和完整性通过应用层来控制
- 表在设计之初,应该考虑到大致的数据级,若表记录小于1000W,尽量使用单表,不建议分表。
- 建议将大字段,访问频率低,或者不需要作为筛选条件的字段拆分到拓展表中,(做好表垂直拆分)
- 控制单实例表的总数,单个表分表数控制在1024以内。
列设计规范
- 正确区分tinyint、int、bigint的范围
- 使用varchar(20)存储手机号,不要使用整数
- 使用int存储ipv4 不要使用char(15)
- 涉及金额使用decimal/varchar,并制定精度
- 不要设计为null的字段,而是用空字符,因为null需要更多的空间,并且使得索引和统计变得更复杂。
索引规范
- 唯一索引使用uniq_[字段名]来命名
- 非唯一索引使用idx_[字段名]来命名
- 不建议在频繁更新的字段上建立索引
- 非必要不要进行JOIN,如果要进行join查询,被join的字段必须类型相同,并建立索引。
- 单张表的索引数量建议控制在5个以内,索引过多,不仅会导致插入更新性能下降,还可能导致MYSQL的索引出错和性能下降
- 组合索引字段数量不建议超过5个,理解组合索引的最左匹配原则,避免重复建设索引。比如你建立了
(x,y,z) 相当于你建立了(x),(x,y),(x,y,z)
SQL规范
- 禁止使用selet ,只获取必要字段,select 会增加cpu/i0/内存、带宽的消耗。
- insert 必须指定字段,禁止使用insert into Table values().指定字段插入,在表结果变更时,能保证对应应用程序无影响。
- 隐私类型转换会使索引失效,导致全表扫描。(比如:手机号码搜索时未转换成字符串)
- 禁止在where后面查询列使用内置函数或者表达式,导致不能命中索引,导致全表扫描
- 禁止负向查询(!=,not like ,no in等)以及%开头的模糊查询,造成不能命中索引,导致全表扫描
- 避免直接返回大结果集造成内存溢出,可采用分段和游标方式。
- 返回结果集时尽量使用limit分页显示。
- 尽量在order by/group by的列上创建索引。
- 大表扫描尽量放在镜像库上去做
- 禁止大表join查询和子查询
- 尽量避免数据库内置函数作为查询条件
- 应用程序尽量捕获SQL异常
表的垂直拆分
垂直拆分:业务模块拆分、商品库,用户库,订单库
水平拆分:对表进行水平拆分(也就是我们说的:分表)
表进行垂直拆分:表的字段过多,字段使用的频率不一。(可以拆分两个表建立1:1关系)
- 将一个属性过多的表,一行数据较大的表,将不同的属性分割到不同的数据库表中。以降低单库表的大小。
特点: - 每个表的结构不一致
- 每个表的数量都是全量
- 表和表之间一定会有一列会进行关联,一般都是主键
原则:
- 将长度较短,访问频率较高的字段放在一个表中,主表
- 将长度较长、访问频率比较低的字段放一个表中
- 将经常访问字段放一个表中。
- 所有表的并集是全量数据。
如何平滑添加字段
场景:在开发时,有时需要给表加字段,在大数据量且分表的情况下,怎么样平滑添加。建议125
1:直接alter table add column,数据量大时不建议,(会产生写锁)
1 | alter table ksd_user add column api_pay_no varchar(32) not null comment '用户扩展订单号' |
2:提前预留字段(不优雅:造成空间浪费,预留多少很难控制,拓展性差)
3:新增一张表,(增加字段),迁移原表数据,在重新命名新表作为原表。
4:放入extinfo(无法使用索引)
5: 提前设计,使用key/value方法存储,新增字段时 ,直接加一个key就好了(优雅)
学习参考