数据库中件设计与实现.ppt

* * * * 淡化 * * 数据库中间件设计与实现 * 纲要 MySQL存在的问题 主流MySQL Proxy方案 中间件的设计与实现 总结 * MySQL存在的问题 读写分离 在客户端中配置所有DB信息，并实现读写分离 DB上下线业务受影响 运维跟开发需同步调整配置 * client db_master db_slave 主从同步 MySQL存在的问题 * 分库分表 客户端改写SQL语句 客户端将SQL路由不同的DB 客户端聚合结果 db1 db3 db2 sql1 sql2 sql3 sql merge result 中间件的目标 * 减轻开发工作量 支持SQL读写分离 支持数据分库分表 减轻运维工作量 无需与开发同步 高可用减少运维工作 主流MySQL Proxy方案 * 主要解决方案 DBProxy Mysql官方产品，但只出到Beta 0.8，基本不维护 BUG多、扩展功能较难 C语言开发 国内衍生：360 Atlas、Meituan DBProxy、Sohu DBProxy... Cobar 功能简单 基本不维护 JAVA开发 阿里内部已发展为TDDL(非代理模式),并在阿里云DRDS中大量使用 国内衍生：MyCat Vitess Youtube开源的数据库扩展及高可用方案，已经用于生产环境 功能强大，但是构架复杂，部署及运维成本较高 GOLANG开发 国内GO开发：Kingshard 中间件核心功能 * 读写分离 数据分库分表 平滑上下线DB 中间件实现 * SQL Parser 数据分片 SQL路由 结果归并 连接池设计 后端DB的高可用方案 高可用方案 安全审计 架构设计 * 整体架构图 SQL Parser * SQL Parser的设计与实现 词法分析器 将SQL切分 语法分析器 根据词法分析器结果和MySQL语法规则生成AST(abstract syntax tree) 相关产品 目前常见的SQL解析器主要有fdb/jsqlparser和Druid SQL 词法分析 语法分析 AST 根据分片规则生成新 SQL 数据分片 * 分片概念 逻辑：将数据落在不同的DB实例中的不同子表中 分片方式：Hash、Range、Time_Range等 Shard key类型：整型、MySQL标准时间类型等 数据到实例采用两级映射方案 shard_key sub_table DB data 数据分片 * select * from tab where id = 10 range hash time config select * from tab_0001 where id = 10 calculate table index SQL路由 * 路由概念 SQL路由是根据分片规则配置，将SQL定位至真正的数据源 结果归并 * 归并概念 结果归并包括4类：普通遍历类、排序类、聚合类和分组类。每种类型都会先根据分页结果跳过不需要的数据。 普通遍历类最为简单，只需按顺序遍历ResultSet的集合即可 排序类结果将结果先排序再输出，因为各分片结果均按照各自条件完成排序，所以采用归并排序算法整合最终结果 分组类最为复杂，需要将所有的ResultSet结果放入内存，使用map-reduce算法分组，最后根据排序和聚合条件做相关处理。最消耗内存，最损失性能的部分即是 连接池设计 * 目标 复用连接，降低后端DB压力 方式 一个DB实例对应一个连接池 连接池个数上限可配置，无空闲连接则阻塞 效果 前端高并发，MySQL负载不会抖动 限制连接池个数，保护后端DB不至于宕机 连接池设计 * middleware DB1 Conn Pool Conn Pool DB2 conn conn conn ...... pop push 连接取出时： 重置字符集 重置Database 后端DB的高可用方案 * 方式 使用独立线程检测DB状态 定期检测每台DB是否正常，周期和重试次数均可配置 效果 自动摘除宕机或网络中断的DB 自动挂载恢复正常的DB middleware DB_Master DB_Slave1 DB_Slave2 高可用方案 * 安全与审计 * 客户端IP限制 用户自定义IP白名单列表 SQL黑名单 用户定义黑名单SQL列表 慢SQL记录 用户自定义慢日志耗时大小 总结 * 普遍存在的两大问题 性能效率问题：采用代理的方式，有性能损耗，跨库查询性能更差。是否有其它更高效方式？ 功能问题：不支持分布式事务。为什么不支持？如何实现分布式事务？ * Thank You * * * * * * 用户使用： 简单高效