展开查看详情
1 . 同程艺⻰
DB Mesh For TiDB&MySQL
2 .⼤纲
๏ 同程艺⻰数据体系介绍
๏ MySQL的接⼊⽅案
๏ TiDB的接⼊⽅案
๏ DB Mesh For TiDB&MySQL
4 .同程艺⻰数据库体系介绍
Applications
Proxy TVS DAL TIDB PD
MongoDB MongoDB
分⽚ 副本集 SQLServer SQLServer
MySQL分⽚ MySQL主从 TIKV
元 Cluster AlwaysOn DB
数 ⼀
MySQL私有云服务 MongoDB服务管理 TIDB管控平台 站
据
管 式
理 平
统 台
收集器 合并器
分发器
DTS平台 MQ ⼤数据平台
6 .DAL组件接⼊
优点：
• 近业务端部署的⽅式，执⾏效率⾼；
• ⽆需额外机器资源部署；
• 去中⼼化，故障影响范围⼩；
• 提供连接池管理、读写分离、⾼可⽤
切换等数据库本身未提供或不完善的
功能；
• 可管理应⽤与DB的“⾎缘关系”；
缺点：
• 多语⾔⽀持难；
• 版本迭代推进难；
• 业务耦合；
• 数据库连接数多；
7 .DB Proxy接⼊
优点：
• 接⼊简单，对业务代码的语⾔⽆要
求；
• 数据库连接数低；
• 提供连接池管理、读写分离、⾼可⽤
切换等数据库本身未提供或不完善的
功能；
缺点：
• 集中化部署,故障影响范围⼤；
• 性能损耗⾼(负载和Proxy)；
• 需要额外提供机器资源部署；
• 单机性能要求⾼；
• ⽆法管理应⽤与DB的“⾎缘关系”；
• 负载均衡稳定性和性能要求极⾼；
8 .负载接⼊
优点：
• 接⼊简单，对业务代码的语⾔⽆
要求；
• ⽆SQL兼容性问题；
• 解决⾼可⽤切换和读负载；
缺点：
• 负载均衡有⽹络消耗
• ⽆Proxy和DAL的访问管控功能
• 负载均衡稳定性和性能要求极
⾼；
10 .TiDB官⽅推荐
优点：
• 接⼊简单，对业务代码的语⾔⽆
要求；
• ⽆SQL兼容性问题；
• 解决TiDB Server⾼可⽤和负载
均衡问题；
缺点：
• 负载均衡有⽹络消耗
• ⽆Proxy和DAL的访问管控功能
• 负载均衡稳定性和性能有要求
(LVS 6年没更新、HAProxy性能
不如LVS、F5太贵)；
11 .DAL接⼊⽅式(同程艺⻰⽬前)
优缺点与前⾯提到的MySQL DAL组件接⼊相同
12 .DB Mesh For TiDB&MySQL
13 .DB Mesh
DB Mesh的理念来⾃于Service Mesh，也被形象称为Sidecar模式(如下图)。业务代码(相当于主驾驶)，外挂⼀
个代理(挎⽃)，代理除了负责服务发现和负载均衡，还负责连接路由、限流、监控和访问⽇志等功能，这些功能
是具体业务⽆关的，属于跨横切⾯关注点范畴。通过这种解耦的部署模式可以极⼤提升基础架服务的版本迭代
推进速度。同时这也是⼀个Cloud Native的解决⽅案，完美适配Kubernetes架构。
14 .DB Mesh
定位：
• Cloud Native
• 新⼀代数据(MySQL、TiDB、Redis等)接⼊⽅案
功能特性：
• 同端⼝多进程(多版本共存)
• 负载均衡
• 读写分离
• 配置热加载、版本热更新
• 服务发现
• 慢SQL统计
• SQL审计
• ⾼性能、低消耗
• 健康检查
• 多类型数据库、多协议接⼊(⽬前只⽀持了MySQL协议)
开发语⾔：
• C++
15 .架构介绍
PS：DB Mesh是架构的名称，DB Sidecar是具体实现功能的服务。
16 .与DAL、DB Proxy存在形态上的差异
DAL接⼊
DB Mesh
DB Proxy接⼊
17 .核⼼模块
协议：前后端MySQL协议
连接管理：负责前后端连接池管理
解析器：解析SQL语句
预处理：绑定参数，prepare,execute;事务处理
路由管理：结合配置中⼼，利⽤应⽤标识和库信息，分配指定
后端连接
监听器：前后端的事件监听
执⾏器：处理接受到的事件，如登录、转发、错误处理等
配置管理：watch配置中⼼，发现配置更新则拉起；启动拉去配
置等
定时器：处理周期任务，统计信息上报等
守护线程：处理运维命令
19 .DB Mesh部署⽅式-1
物理机、虚机、容器中部署
20 .DB Mesh部署⽅式-2
Kubernetes 伴⽣模式
22 .应⽤如何连接DB
库名 应⽤标识
jdbc:mysql://127.0.0.1:3306/dbName@si_test_key?
user=account&password=123456&useUnicode=true&characterEncoding=utf8
账号 密码
以上标出的部分是需要定义的参数，通过库名和应⽤标识进⾏连接路由，账号密码进⾏鉴权。
23 .连接信息查看
查看连接池，显示后端连接的统计信息，以及后端站点的健康状况等。
显示后端连接真实使⽤情况
24 .测试
测试数据：
• 范围包含稳定性、异常、运维、容量、性能5个
⽅向
• 涉及测试⽤例88个
• 测试⼈⼒投⼊3⼈/⽉
压测场景：
• ⽤压测⼯具在相同压⼒下，对DB Sidecar不同进
程量进⾏压测
• 根据线上业务场景，测试⽤例中读写⽐例为9:1
• 50-80字段的表结构
性能数据：
• 1进程3线程: 6W QPS
• 5进程3线程: 15W QPS
产线情况：
• 核⼼项⽬已经有应⽤在⽣产环境使⽤
25 .DB Mesh优点
• 可以⽀持各种语⾔(可以使⽤MySQL协议)的业务代码
• 近业务端部署,执⾏效率⾼
• 与业务代码⽆耦合关系
• 解决了DAL和DB Proxy的存在缺点(参照前⽂)
• 可以⽀持TiDB的接⼊,并且可以管控TiDB的接⼊,优于⽬前LVS、HAProxy的接⼊⽅式
• 可完美适配Kubernetes的部署模式
• 访问数据库的应⽤和数据库形成⼀个巨⼤的⽹格体系，将散落在系统各个⻆落中的数据
库统⼀治理起来
• 插件式设计，未来可以扩展出⽀持其他协议的Sidecar(Redis、PG、ES等)
27 .开源孵化
开源形式：
• 借助PingCAP项⽬孵化的⽅式进⾏开源
• 核⼼代码公司内部与外部版本保持同步
参与⼈员：
• 3位从事过数据库内核研发、中间件研发、10+年C++程序研发的开发⼈员(DEV⻆⾊)
• 1位从事多年数据库运维的DBA(PM⻆⾊)
开源时间：
• ⽬前正在紧锣密⿎的筹备中，预计明年春季
28 .开源孵化的第⼀期核⼼功能
功能模块 状态 进展
负载均衡 已实现 进⾏中
读写分离 已实现 进⾏中
配置管理 需改造 进⾏中
连接管理 需改造 进⾏中
配置热加载 已实现 进⾏中
服务发现 已实现 进⾏中
监控信息上报 需改造 进⾏中
同端⼝多进程 已实现 进⾏中
慢SQL统计 已实现 进⾏中
守护进程管理 已实现 进⾏中
29 . 酒店、机票、⽕⻋票，
在微信⽀付⾥订，就对了！
热门城市
