sharding-jdbc-how2work 当当的sharding-jdbc剖析

Posted 2020-06-13

> 空开 否则右边挡了,好不优雅的办法

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

 

 

 

 

JDBC出发点

整体思路：实现JDBC规范的接口 分析com.dangdang.ddframe.rdb.sharding.jdbc包

  实现javax.sql.DataSource接口 ShardingDataSource

  实现java.sql.Connection接口 ShardingConnection

  实现java.sql.Statement ShardingStatement

  实现java.sql.PreparedStatement ShardingPreparedStatement

  实现java.sql.ResultSet AbstractShardingResultSet

重新实现的方式

  AbstractUnsupportedOperationXXXX描述不支持的接口实现 通过这一系列的类可以看出不支持哪些操作

  AbstractXXXXAdapter 这一层意义？

  WrapperAdapter

具体实现分析

  ShardingDataSource

   根据ShardingRule实例准备DatabaseMetaData实例 用于构建ShardingConnection实例

   准备DatabaseMetaData实例的过程： 根据原有Datasource获取到数据库产品的信息 一次准备的所有数据源必须是同一种数据库产品 不能既有MySql又有DB2

  ShardingConnection

   主要完成createStatement、prepareStatement接口的实现

   实现createStatement、prepareStatement接口 主要过程是创建ShardingStatement、ShardingPreparedStatement实例 创建上述两实例需要SQLRouteEngine实例

   SQLRouteEngine实例实在connection构造的时候完成创建 需要ShardingRule、DatabaseType

   SQLRouteEngine干什么用的呢？用于分库分表的规则逻辑的接入点

  ShardingStatement

   实现java.sql.Statement接口 不支持的操作参见AbstractUnsupportedOperationStatement

   currentResultSet = ResultSetFactory.getResultSet(generateExecutor(sql).executeQuery(), mergeContext);

  ShardingPreparedStatement

  AbstractShardingResultSet

Executor

根据SQLRouteEngine与sql 组装出StatementExecutor

  route出SQLRouteResult

  SQLRouteResult拿到执行单元SQLExecutionUnit 执行单元包装了sql及其相应的dataSource的key名

  拿到MergeContext

StatementExecutor本质在于包装了多个Statement及相应sql 在代码中用StatementEntity做了表示 这里的sql已经是用物理表名置换了逻辑表名后的sql 这里的Statement已经是相应jdbc driver对应的原生的Statement

SQLRouteEngine

1. route是其核心的对外暴露的接口

  parseSQL接口用SQLParseEngine parse出SQLParsedResult

  根据parse出的SQLParsedResult结果实例中的 ConditionContext、逻辑表名、SQLBuilder实例 与shardingRule(SQLRouteEngine的实例变量) 加工出SQLExecutionUnit实例列表

1.1 parseSQL

  1. SQLParserFactory根据逻辑sql(还没有实际的物理表名的sql)、分片列名、数据库类型、查询的条件参数创建SQLParseEngine

  1.1 创建SQLParseEngine主要过程有： a. 用阿里的druid解析出语法树com.alibaba.druid.sql.ast.SQLStatement b. 根据sql语句是增删改查来决定用哪种visitor实例(用于后置处理)

  1.2 parse过程 依赖visitor 含有or条件的特殊处理

   具体的visitor

   TODO or条件的特殊处理

1.2 route

  需要的要素：shardingRule(SQLRouteEngine的实例变量), ConditionContext,逻辑表名,SQLBuilder实例

  又分三种： SingleTableRouter--route-->SingleRoutingResult //单表(逻辑表)操作 BindingTablesRouter--route-->BindingRoutingResult MixedTablesRouter--route-->RoutingResult(CartesianTablesRouter)

  SingleTableRouter

   routeDataSources

    ShardingValue DatabaseShardingStrategy.doSharding

   routeTables

    ShardingValue TableShardingStrategy.doSharding

  BindingTablesRouter

   BindingRoutingResult.bind

   BindingRoutingDataSource.bind

   BindingRoutingTableFactor

visitor

五种。 看懂visitor前提是要了解 编译器常用的访问者这种设计模式

  com.dangdang.ddframe.rdb.sharding.parser.visitor.basic.mysql MySQLInsertVisitor MySQLDeleteVisitor MySQLSelectVisitor MySQLUpdateVisitor OrVisitor

visitor通过ParseContex 做了mergeCurrentConditionContext、getParsedResult、 visitor还getSQLBuilder

AbstractMySQLVisitor 增删改查都用到的 重新实现visit以下类型AST节点的逻辑： SQLVariantRefExpr,SQLExprTableSource,SQLPropertyExpr, SQLBinaryOpExpr,SQLInListExpr,SQLBetweenExpr

  SQLVariantRefExpr sql中的问号占位符，:xxx这种命名参数， @max_order_id:= 这种 select @max_order_id:=max(order_id) from order where id=? and user_id=:userId

   父类不仅用@@ 替换?, 同时用实际参数值替换了?占位符 sharding-jdbc将占位符换成真正参数值的 动作交由ShardingPreparedStatement完成

  SQLExprTableSource select * from order o where o.id=1 from后面的order就是SQLExprTableSource select * from (select * from order o where o.id=1) order_alias from后面的order是SQLExprTableSource，但order_alias不是 order_alias 是SQLSubqueryTableSource SQLSubqueryTableSource与SQLExprTableSource 都是SQLTableSourceImpl的子类

   插入parseContext.addTable(x)逻辑： 1. 处理表名及其别名中特殊字符--> []`‘\\ 2. 将表名及其别名加入RouteContext

  SQLPropertyExpr select o.name from order o where o.id=1 此处的name和id都是SQLPropertyExpr 接在表别名点号后面的是SQLPropertyExpr

   针对"select * from T_ORDER where T_ORDER.order_id=1002 这种sql重新实现此类型节点的visitor 过程：将T_ORDER.order_id换成别名t_order.order_id 其余的SQLPropertyExpr沿用父类逻辑

  SQLBinaryOpExpr select * from order o where o.id=1 左值o.id 右值 1 就是描述运算的 select 1+1 1+1也是

   1. 发现有or操作时， 要将parseContext中存在or条件标志置成true 便于后面特殊处理 2. 发现有=(等于比较)操作时将其加入到 parseContext的ConditionContext中

  SQLInListExpr select * from user u where u.id in (1,3,4,5) targetList是in后面的列表 expr是in前面的表达式

   in操作与上面=操作的处理相同

  SQLBetweenExpr select * from t_order_0 where order_id between 1004 and 1008

   between与上面=操作相同

MySQLSelectVisitor 重新实现/更新visit以下类型AST节点的逻辑： MySqlSelectQueryBlock,SQLSelectItem,SQLAggregateExpr SQLOrderBy,MySqlSelectGroupByExpr, MySqlSelectQueryBlock.Limit, endVisit(final SQLSelectStatement x)

  MySqlSelectQueryBlock 插入逻辑： 告诉程序当前在处理哪个表的子查询

  SQLSelectItem 插入逻辑： 更新itemIndex给处理SQLAggregateExpr时使用

  SQLAggregateExpr 聚合： String[] AGGREGATE_FUNCTIONS = { "AVG", "COUNT", "MAX", "MIN", "STDDEV", "SUM" }

   对分库分表时的聚合插入逻辑处理 主要是分析出是哪种聚合 聚合的哪一列 然后扔进ParseContext的MergeContext

   使用逻辑表名查询时,聚合计算是不分片的 使用物理表名查询时， 聚合计算是报错的，sharding不认识物理表名

  SQLOrderBy

   类似SQLAggregateExpr的处理 对分库分表时的order by插入逻辑处理 主要是分析出是哪种排序形式 是哪一列(支持多列) 然后扔进ParseContext的MergeContext

  MySqlSelectGroupByExpr

   类似SQLAggregateExpr、SQLOrderBy的处理

  MySqlSelectQueryBlock.Limit

   处理ParseContext的MergeContext的部分 类似SQLAggregateExpr、SQLOrderBy的处理 context中的offset与rowcount是原有sql中真是的值

   多一个逻辑： 到实际物理表查询的sql在此处被改写了, offset从0开始，rowcount是原有sql里的offset加上原有sql里的rowcount 当然同时支持(兼容)?占位符的情况

   日志更直观： Logic SQL: select * from t_order o order by o.order_id limit 1,2 route sql to db: [db0] sql: [SELECT * FROM t_order_0 o ORDER BY o.order_id LIMIT 0, 3] route sql to db: [db0] sql: [SELECT * FROM t_order_1 o ORDER BY o.order_id LIMIT 0, 3]

  endVisit(final SQLSelectStatement x)

   当一个查询结束后 从MergeContext拿到AggregationColumns 进行加工，举例，主要逻辑如下： select avg(order_id) from t_order 加工成 SELECT AVG(order_id)[Token(, COUNT(order_id) AS sharding_gen_1, SUM(order_id) AS sharding_gen_2)] FROM [Token(t_order)] 主要是补了sum和count

MySQLDeleteVisitor

  更新MySqlDeleteStatement处理逻辑 将当前表名及其别名加入RouteContext 感觉跟AbstractMySQLVisitor里对SQLExprTableSource 处理逻辑有重复部分

MySQLInsertVisitor

  将当前表名及其别名加入RouteContext 同delete

  插入的列也需要纳入ParseContext的ConditionContext管理 以保证插入到正确的表中！

MySQLUpdateVisitor

  将当前表名及其别名加入RouteContext 同delete

  没有其他处理逻辑了 那么分片键再次更新就不能正确的落到相应的物理表中了 分片键值更新 分片键还作为update的where条件 update t_order_0 set order_id=1011 where order_id=1002