Sharding-JDBC

在上一篇文章讲述了如何使用Mybatis-plus自动生成代码，生成的代码具有单表操作数据库的能力，节约了开发时间。然后讲述了如何在Spring Boot中整合Mybatis-Plus。这篇文章讲述如何使用Mybatis-Plus的增强功能：自动填充功能和查询分页功能。 Mybatis-Plus自动填充功能 在Matrix-web项目中，数据库的所有表都有四个公共字段，即create_by、create_time、update_by、update_time ，即存储了表数据的创建人、创建时间、更新时间、更新人。在对表插入一条数据的时候，需要自动填充四个字段，对表数据更新操作，需要更新后2个字段。但是如果在每个插入和更新业务逻辑里面， 手动的填充这四个字段，增加了工作量。幸好mybatis-plus有一个自动更新的插件。 实现自动填充功能很简单，只需要实现MetaObjectHandler接口和实现填充逻辑，并把它注入到spring ioc容器中即可。其中下面的代码UserUtils.getCurrentUserWithDefault();即获取当前请求的用户，在权限那一篇文章有讲到过，在这里不再重复；然后加上注解@Component注入到Spring ioc容器里面去。 @Component @Slf4j public class MyMetaObjectHandler

1、Sharding-JDBC简介 1) 是轻量级的Java框架, 是增强版的JDBC驱动 2) 主要目的: 是简化分库分表之后的数据相关操作 2 Sharding-JDBC 水平分表操作 3 Sharding-Proxy 分库分表操作 来源： oschina 链接： https://my.oschina.net/liwanghong/blog/4341226

目录 1.为什么需要中间件 不分库篇 （1）普通的应用程序 （2）并发读写大--缓存 （3）缓存过期问题--读写分离+缓存 （4）隔离对DAO层影响--数据库中间件+读写分离+缓存 （5）业务模块多--集群+数据库中间件+读写分离+缓存 分库篇 （1）业务模块多，数据总量大--分库+缓存 （2）分库对Dao层代码影响--分库+数据库中间件+缓存 （3）读写压力大--分库+读写分离+数据库中间件+缓存 2.数据库中间价设计要点 （1）垂直拆分 （2）水平拆分 （3）无论是垂直拆分、水平拆分，都有共同的技术难点 （4）数据库中间件的两种实现模式 （5）常用数据库中间件简介 小结 1.为什么需要中间件 不分库篇 （1）普通的应用程序 数据库访问 数据库存储的数据量不是很大，但并发的读写操作都很大，超过数据库服务器的处理能力。 阿里云-RDS版MySQL性能测试结果（MySQL 5.6） TPS：每秒钟处理事务数量 QPS：每秒钟SQL语句执行条数（并发请求数） （2）并发读写大–缓存 业务场景 ：数据量不是很大，仅并发读写超过数据库服务器的处理能力 解决办法 ： 加缓存 （3）缓存过期问题–读写分离+缓存 业务场景 ：缓存会有过期命不中，还是会有大量的读和全部的写操作将请求数据库，如果数据库支持不起，怎么办？ 解决办法 ：读写分离+缓存 （4）隔离对DAO层影响–数据库中间件+读写分离

一下博文部分为转载内容： 数据库分库分表从互联网时×××启至今，一直是热门话题。在NoSQL横行的今天，关系型数据库凭借其稳定、查询灵活、兼容等特性，仍被大多数公司作为首选数据库。因此，合理采用分库分表技术应对海量数据和高并发对数据库的冲击，是各大互联网公司不可避免的问题。 虽然很多公司都致力于开发自己的分库分表中间件，但截止目前，仍无完美的开源解决方案覆盖此领域。 分库分表适用场景 分库分表用于应对当前互联网常见的两个场景——大数据量和高并发。通常分为垂直拆分和水平拆分两种。 垂直拆分是根据业务将一个库（表）拆分为多个库（表）。如：将经常和不常访问的字段拆分至不同的库或表中。由于与业务关系密切，目前的分库分表产品均使用水平拆分方式。 水平拆分则是根据分片算法将一个库（表）拆分为多个库（表）。如：按照ID的最后一位以3取余，尾数是1的放入第1个库（表），尾数是2的放入第2个库（表）等。 关系型数据库在大于一定数据量的情况下检索性能会急剧下降。在面对互联网海量数据情况时，所有数据都存于一张表，显然会轻易超过数据库表可承受的数据量阀值。这个单表可承受的数据量阀值，需根据数据库和并发量的差异，通过实际测试获得。 单纯的分表虽然可以解决数据量过大导致检索变慢的问题，但无法解决过多并发请求访问同一个库，导致数据库响应变慢的问题。所以通常水平拆分都至少要采用分库的方式

配置示例 数据分片 dataSources: ds0: !!org .apache.commons.dbcp.BasicDataSource driverClassName: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/ds0 username: root password: ds1: !!org .apache.commons.dbcp.BasicDataSource driverClassName: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/ds1 username: root password: shardingRule: tables: t_order: actualDataNodes: ds${0..1}.t_order${0..1} databaseStrategy: inline: shardingColumn: user_id algorithmExpression: ds${user_id % 2 } tableStrategy: inline: shardingColumn: order_id algorithmExpression: t_order${order_id % 2 } keyGenerator: type:

首先采用Mysql存储千亿级的数据，确实是一项非常大的挑战。Mysql单表确实可以存储10亿级的数据，只是这个时候性能非常差，项目中大量的实验证明，Mysql单表容量在500万左右，性能处于最佳状态。 针对大表的优化，主要是通过数据库分库分表来解决， 目前比较普遍的方案有三个：分区，分库分表，NoSql/NewSql。 实际项目中，这三种方案是结合的，目前绝大部分系统的核心数据都是以RDBMS存储为主，NoSql/NewSql存储为辅。 分区 首先来了解一下分区方案。 分区表是由多个相关的底层表实现的。这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区，存储引擎管理分区的各个底层表和管理普通表一样（所有的底层表都必须使用相同的存储引擎），分区表的索引只是在各个底层表上各自加上一个相同的索引。这个方案对用户屏蔽了sharding的细节，即使查询条件没有sharding column，它也能正常工作（只是这时候性能一般）。 不过它的缺点很明显： 很多的资源都受到单机的限制，例如连接数，网络吞吐等。如何进行分区，在实际应用中是一个非常关键的要素之一。 下面开始举例： 以客户信息为例，客户数据量5000万加，项目背景要求保存客户的银行卡绑定关系，客户的证件绑定关系，以及客户绑定的业务信息。 此业务背景下，该如何设计数据库呢。项目一期的时候，我们建立了一张客户业务绑定关系表

为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？ 面试官心理分析 其实这块肯定是扯到 高并发 了，因为分库分表一定是为了 支撑高并发、数据量大 两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！ 面试题剖析 为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？） 说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。 我先给大家抛出来一个场景。 假如我们现在是一个小创业公司（或者是一个 BAT 公司刚兴起的一个新部门），现在注册用户就 20 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10 个。我的天，就这种系统，随便找一个有几年工作经验的，然后带几个刚培训出来的，随便干干都可以。 结果没想到我们运气居然这么好，碰上个 CEO 带着我们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表数据量 10 万条！高峰期每秒最大请求达到 1000！同时公司还顺带着融资了两轮，进账了几个亿人民币啊

在Matrix-web后台管理系统中，使用到了数据库的读写分离技术。采用的开源的Sharding-JDBC作为数据库读写分离的框架。Matrix-Web后台数据库这一块采用的技术栈如下： 使用Mybatis-Plus作为ORM框架 使用Druid或者HikariCP作为数据库连接池 使用Sharding-JDBC 作为数据库读写分离的框架 本篇文章将讲述在Sharding-JDBC在Matrix-Web中的应用。 Sharding-JDBC简介 Sharding-JDBC是的分布式数据库中间件解决方案。Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）是3款相互独立的产品，共同 组成了ShardingSphere。Sharding-JDBC定位于轻量级的Java框架，它使用客户端直连数据库，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。 适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。 架构图如下

前言 100道MySQL数据库经典面试题解析，已经上传github啦 https://github.com/whx123/JavaHome/tree/master/Java面试题集结号 公众号：捡田螺的小男孩 数据库 1. MySQL 索引使用有哪些注意事项呢？ 可以从三个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景，索引规则 索引哪些情况会失效 查询条件包含or，可能导致索引失效 如何字段类型是字符串，where时一定用引号括起来，否则索引失效 like通配符可能导致索引失效。 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。 在索引列上使用mysql的内置函数，索引失效。 对索引列运算（如，+、-、*、/），索引失效。 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。 索引字段上使用is null， is not null，可能导致索引失效。 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。 mysql估计使用全表扫描要比使用索引快,则不使用索引。 后端程序员必备：索引失效的十大杂症 索引不适合哪些场景 数据量少的不适合加索引 更新比较频繁的也不适合加索引 区分度低的字段不适合加索引（如性别） 索引的一些潜规则 覆盖索引 回表 索引数据结构（B+树） 最左前缀原则 索引下推 2. MySQL

一、概念先行 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分片