Sharding-JDBC

摘要 范围（range）分表也需要确切（precise）分表策略，这点很重要。 确切分表根据分表字段确定数据落在哪一个库。 范围分表策略可以根据分表字段的上下限决定从哪些表去查找数据。 数据库脚本 DROP TABLE IF EXISTS `t_order201909`; CREATE TABLE `t_order201909` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(32) NULL DEFAULT NULL, `order_id` bigint(32) NULL DEFAULT NULL, `title` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `content` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `create_time` datetime(0) NULL DEFAULT NULL, `update_time` datetime(0) NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE ) ENGINE =

sharding-jdbc 中使用了 position 作为表的字段名，造成不能切分 来源： oschina 链接： https://my.oschina.net/alyouge/blog/3135137

概述 热点数据通俗的讲是指被高频使用到的数据，比如某些热点事件，由于网络的发酵效应，短时间能够达到几十万甚至上百万的并发量，针对这类场景，我们需要分析系统瓶颈所在，以及应对的技术实现 方案讲解 大并发架构演进 1、图1和图2的区别是中间会有一层web缓存服务器，该服务它可以由nginx+lua+redis进行设计完成，缓存层的热点数据分散，将会在后续的‘高并发度’章节做介绍。 2、热点数据肯定能在web层的缓存服务器被拦截住，防止把大量的请求打到应用服务器，但是对于非热点的数据穿透缓存后会请求至DB，这部分数据每秒几千的QPS对DB造成的压力也是非常大的，这个时候我们需要一定的方案，保证请求的时效性，就是如何降低DB层面的IO次数 场景分类 热点数据并发分为读和写两种场景，日常高并发遇到的大多数都是读场景，无论是采用何种的架构设计，都需要在缓存层和DB层面做热点数据的分散，本章着重介绍后者 原理分析 大家都知道对热点数据分散后，系统的性能会有显著提升，是什么原理导致的，接下来我们探讨一下db存储的一些关键知识，上面两个是大家经常用到的两种mysql存储引擎，尤其是后者，基本上笔者在工作中遇到的绝大多数的表都定义成了innodb引擎，两者的差异在哪里？使用场景的区别在什么地方？ 1、读数据 myisam ：与innodb一样都采用BTREE实现，myisam是非聚集索引

【引用官网】 为每个分片查询维持一个独立的数据库连接，可以更加有效的利用多线程来提升执行效率。为每个数据库连接开启独立的线程，可以将I/O所产生的消耗并行处理，连接模式（Connection Mode）的概念，将其划分为内存限制模式（MEMORY_STRICTLY）和连接限制模式（CONNECTION_STRICTLY）这两种类型 内存限制模式 ：使用此模式的前提是，ShardingSphere对一次操作所耗费的数据库连接数量不做限制。如果实际执行的SQL需要对某数据库实例中的200张表做操作，则对每张表创建一个新的数据库连接，并通过多线程的方式并发处理，以达成执行效率最大化。并且在SQL满足条件情况下，优先选择流式归并，以防止出现内存溢出或避免频繁垃圾回收情况 连接限制模式 ：使用此模式的前提是，ShardingSphere严格控制对一次操作所耗费的数据库连接数量。如果实际执行的SQL需要对某数据库实例中的200张表做操作，那么只会创建唯一的数据库连接，并对其200张表串行处理。如果一次操作中的分片散落在不同的数据库，仍然采用多线程处理对不同库的操作，但每个库的每次操作仍然只创建一个唯一的数据库连接。这样即可以防止对一次请求对数据库连接占用过多所带来的问题。该模式始终选择内存归并 case: 本文主要以SELECT i.* FROM t_order o, t_order_item

【引用官网】在包含分表的场景中，需要将分表配置中的逻辑表名称改写为路由之后所获取的真实表名称。仅分库则不需要表名称的改写。除此之外，还包括补列和分页信息修正等内容，如图: 本文主要以SELECT i.* FROM t_order_1 o, t_order_item_1 i WHERE o.order_id = i.order_id and o.order_id = ? and o.user_id = ?一个简单查询语句，来分析ss大致如何来改写sql的，不同类型sql改写需自行查看对应的sql token生成器 比如分页查看OffsetTokenGenerator 1.BaseShardingEngine#shard执行改写，主要查看rewriteAndConvert方法 @RequiredArgsConstructor public abstract class BaseShardingEngine { //分库分表规则 private final ShardingRule shardingRule; //分片参数 private final ShardingProperties shardingProperties; //分片元数据 private final ShardingMetaData metaData; //路由钩子 private final

路由引擎主要分为两大类： 分片路由 （直接路由、标准路由、笛卡尔积路由） 广播路由 （全库表路由、全库路由、全实例路由、单播路由、阻断路由） 具体路由类型含义参考官网路由引擎 https://shardingsphere.apache.org/document/current/cn/features/sharding/principle/route/ 主要分析查询路由 1.路由ParsingSQLRouter#route入口 @RequiredArgsConstructor public final class ParsingSQLRouter implements ShardingRouter { @Override public SQLRouteResult route(final SQLStatement sqlStatement, final List<Object> parameters) { //优化，处理条件占位符参数与真实数据、分页、group by etc. OptimizedStatement optimizedStatement = OptimizeEngineFactory.newInstance(shardingRule, shardingMetaData.getTable(), sqlStatement, parameters).optimize();

Sharding主要利用 ANTLR4 来解析SQL，以mysql为例，分析源码前可以先了解以下三点： antlr4，如何编写 .g4 语法文件 mysql 语法可以参考 https://dev.mysql.com/doc/refman/8.0/en/sql-syntax-data-manipulation.html mysql g4文件编写可以参考 https://github.com/antlr/grammars-v4/blob/master/mysql 源码分析 1.解析入口ParsingSQLRouter#parse /** * 解析sql * * @param logicSQL 逻辑sql * @param useCache 是否缓存解析后的结果 * @return */ @Override public SQLStatement parse(final String logicSQL, final boolean useCache) { //解析前钩子，如:调用链etx parsingHook.start(logicSQL); try { //解析SQL SQLStatement result = new ShardingSQLParseEntry(databaseType, shardingMetaData.getTable(), parsingResultCache

本文主要分析一下sharding的上下文 ShardingContent ，ShardingContent主要做了那些功能呢？主要有两部分： 数据源分片元数据 主要根据数据源连接获取对应的url，通过解析url参数来封装数据源分片元数据 表分片元数据 主要根据数据节点来获取真实表的元数据 源码分析 1.ShardingContext构造，主要分析ShardingTableMetaData public ShardingContext(final Map<String, DataSource> dataSourceMap, final ShardingRule shardingRule, final DatabaseType databaseType, final Properties props) throws SQLException { this.shardingRule = shardingRule; //获取数据源原始元数据信息 this.cachedDatabaseMetaData = createCachedDatabaseMetaData(dataSourceMap); //数据源类型 this.databaseType = databaseType; //sharding 配置参数 //比如：sql打印、线程池大小配置等 shardingProperties =

Sharding核心配置主要如下（官网）： 分片规则 分片规则配置的总入口。包含数据源配置、表配置、绑定表配置以及读写分离配置等 数据源配置 真实数据源列表 表配置 逻辑表名称、数据节点与分表规则的配置 数据节点配置 用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式 分片策略配置 对于分片策略存有数据源分片策略和表分片策略两种维度 数据源分片策略： 对应于DatabaseShardingStrategy。用于配置数据被分配的目标数据源 表分片策略 对应于TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在与该数据的目标数据源内。故表分片策略是依赖与数据源分片策略的结果的 自增主键生成策略 通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。 接下来对各个核心配置进行分析： 以多主多从读写分离、表分片为例 public final class ShardingMasterSlaveConfigurationPrecise implements ExampleConfiguration { @Override public DataSource getDataSource() throws SQLException { ShardingRuleConfiguration shardingRuleConfig

分析源码前，先阅读一遍官方文档 读写分离 ；主要记录学习一下，公众号： 帽爹的技术轮子 核心概念 主库：添加、更新以及删除数据操作 从库：查询数据操作所使用的数据库，可支持多从库 一主多从读写分离，多主多从需用使用sharding 源码分析 1.启动入口: public class JavaConfigurationExample { // private static ShardingType shardingType = ShardingType.SHARDING_DATABASES; // private static ShardingType shardingType = ShardingType.SHARDING_TABLES; // private static ShardingType shardingType = ShardingType.SHARDING_DATABASES_AND_TABLES; private static ShardingType shardingType = ShardingType.MASTER_SLAVE; // private static ShardingType shardingType = ShardingType.SHARDING_MASTER_SLAVE; // private static ShardingType