开源MySQL分布式中间件剖析.pptx

dble-开源MySQL分布式中间件剖析 目录 CONTENTS 一、dble 简介 二、分布式事务实现 三、复杂查询实现 四、查询优化举例 分布式系统架构示意图 开源分布式中间件d[ou]ble 开源分布式中间件d[ou]ble dble是基于MyCat的企业级加强版的sharding中间件 优化代码结构 Bug修复(100+) 核心功能完善（例：分布式事务，SQL支持度等） 复杂查询的支持与改进 非核心功能选择性裁减（例如异构数据库支持等） 项目地址:/actiontech/dble dble 功能特性 项目地址:/actiontech/dble 分布式事务实现 分布式事务问题的产生 显式分布式事务：转账 隐式分布式事务：发午餐补助 分布式事务的实现-用普通事务简单实现 第一阶段：执行 第二阶段：提交 分布式事务的实现-普通事务实现方式的问题 导致数据不一致可能的场景 网络闪断 参与者数据库服务故障 参与者数据库宿主机宕机 协调者故障 协调者宿主机宕机 分布式事务的实现-MySQL XA事务 XA事务执行阶段 XA事务PREPARE阶段 XA事务COMMIT阶段 分布式事务的实现- MySQL XA事务 网络闪断： 已经完成PREPARE的XA事务， 即使连接断开，事务状态也 不会丢失。可以新建连接继 续提交 中间件可以设定次数阈值， 多次执行，直到成功。 分布式事务的实现- MySQL XA事务 参与者数据库服务故障 MySQL 5.7的 PREPARE状态会写入binlog 即使数据库服务重启， PREPARE状态也不 会丢失。 中间件可以在数据库服务恢复后，继续提 交。 分布式事务的实现- MySQL XA事务 参与者数据库宿主机宕机 由于MySQL 5.7的 PREPARE状态会进binlog， 如果数据结点采用了半同步等高可用方式， XA事务的PREPARE状态会同步到slave机器 上. 即使发生了主从切换，状态也仍然不丢失 中间件可以在高可用切换之后，继续提交。 分布式事务的实现- MySQL XA事务 协调者进程级故障： 观察结点状态如下： NODE1： NODE2: 能否判断NODE 2上的事务该提交or回滚？ 分布式事务的实现- MySQL XA事务 (协调者进程级故障) 无法判断node2上的事务该提交or回滚! 可能情况1： 可能情况2： 分布式事务的实现- MySQL XA事务 协调者进程级故障： 解决方案： 日志先行。 在XA PREPARE 和 XA COMMIT 之前 先将状态日志落盘。 异常发生后，可以根据日志进行手动恢复 或者自动恢复。 衍生问题： 写日志可能成为性能瓶颈 分布式事务的实现- MySQL XA事务 协调者写日志性能问题: 启发： MySQL Group Commit： 思路 ： dble Group Commit： 分布式事务的实现- MySQL XA事务 协调者宿主机故障： 需要状态日志高可用： （Road Map） 写入ZooKeeper,Consul 等 分布式事务的实现- MySQL XA事务 MySQL XA 事务实现分布式事务复盘 优点： 大幅度提高了分布式事务的健壮性。 在发生一些常见故障时候，能够做到数据的最终一致性。 缺点： 一定程度上降低了性能（写日志，多次网络交互等）。 限制： 需要工程实践上的外部依赖。 XA PREPARE状态不丢失 - MySQL5.7 XA实现,MySQL配置。 数据结点服务器故障- 数据节点的MySQL高可用 状态日志的不丢失-日志的高可用。 复杂查询实现 预备知识-一般中间件执行逻辑 一般中间件内部执行逻辑 待解决问题： 复杂聚合 例:select count(distinct column) … JOIN UNION Sub Query 以上混合复杂语句 预备知识-一般中间件执行逻辑 工程上的解决方式： 复杂聚合：修改业务逻辑避开 JOIN :尽量使用ER 表， global 表 UNION：修改业务逻辑避开 Sub Query：修改业务逻辑避开 这些方法都不错，但在不同和场景下， 成本代价相对高昂 有没有通用的解决方式呢？ 复杂查询实现-关系代数 复杂查询实现思路:关系代数 查询树 1.解析SQL时候，将SQL转为基本元组，以及对元组进行关系运算，构建查询树 。 2.将基本元组及可下发的运算作为查询树的叶子节点，下发到物理数据结点查询。 3.结果集返回后，不可下发的运算作为查询树的非叶子节点对子树返回结果处理。 关系代数（部分） 复杂查询实现-JOIN JOIN 举例： select * from table1 a inner join table2 b on a.id =b.id ; table1 有四个分片