雷海林 - TDSQL在微众银行核心交易系统中的实践

宰父欣怿

2018/05/13 发布于 技术 分类

我们需要什么样的MySQL ?如果MySQL性能足够强大,MySQL一致性切换足够完善,MySQL不需要关心分库分表,MySQL不需要关心容量不足。那么,代码会比现在简单,运维会比现在简单。而简单意味着,健壮。下一步的规划,按组扩容,集群虚拟化。引入docker来更灵活地管理set和节点,加强资源隔离。

文字内容
2. TDSQL架构分享 腾讯 - 计费平台部 harlylei
3. • harlylei(雷海林) • 腾讯 / TEG / 计费平台部 • 2007年加入公司,10年以上的Linux后台 Server开发经验,目前主要从事分布式 Cache,实时大数据处理引擎,分布式 MySQL(TDSQL)设计和开发工作。
4. 米大师 数据层解决方案 联机交易 数据层解决方案 金融云 敬请期待…
5. 1. 我们需要什么样的MySQL 2. 系统结构 3. 解决的几个重要问题 a. 自动扩容缩容,透明分表 b. 高一致性容灾 c. 高可用性的保障机制 4. 目前的运营数据 5. 展望
6. 百亿级的账户,订单数据 百亿级的日交易流水 十万级别每秒并发 毫秒级交易响应 —— 易伸缩,高并发 一分不差的银行级业务 —— 高一致性的容灾 7 * 24 小时的不间断服务 —— 自动容灾,自动扩容 如果: MySQL性能足够强大 MySQL一致性切换足够完善 MySQL不需要关心分库分表 MySQL不需要关心容量不足 那么: 代码会比现在简单 运维会比现在简单 而简单意味着 —— 健壮
7. • 继续通过MySQL API和sql接口访问集群 • 节点异常自动切换,切换过程保证数据零丢失,管好钱袋子 • 按需自动扩容/缩容,以支撑业务爆发式增长,扩容过程对业务 基本上无感知 • 业务之间支持隔离,集群自身具备流控机制 • 对SQL语句做实时的时耗统计,慢查询分析,异常SQL拒绝等
8. ScShcehdeudluelrer 1.从zk拉取DDL任务,并在实际的mysql实例上执行 2.从zk获取状态,生成扩容任务 3.控制set内的主备切换 4.多个scheduler自身通过kp的选举实现容灾 1.识别出ddl操作,并以任务形式保存到zookeeper 2.识别出dml操作,进行sql转换并发到对应的set中的主或者备机 3.收集set内各个节点的应答,组合处理之后返回给前端应用api 4.Watch zookeeper,拉取路由,权限等信息 网关 应用 MySQL API 网关 网关 ZooKeeper 解释,转换sql分发 Set1 主 MySQL+Agent 1.监控实例状态并上报到zk 2.监控表的状态并上报到zk 3.从zk拉取迁移任务并执行 4.参与主备切换流程 备1 MySQL+Agent 备N MySQL+Agent SetM 主 MySQL+Agent 备1 MySQL+Agent 备N MySQL+Agent
9. • 规则(水平扩容还是垂直扩容) • 标的:Table • 最小粒度:SET • 即一个伸缩任务应该是:将某个Table的容量伸缩n个SET
10. 谁要扩? 扩到哪? 怎么扩? • 如何发现源头? • 如何选择目标? • 迁移谁? • 是否分裂表?分裂多少? 监控是基础,调度是核心
11. 资源级 • CPU • 内存 • 磁盘空间 • 磁盘IO • 网络IO 业务级 • 时延 • 请求量 • 记录数
12. • 伸缩方式 • 整表迁移 • 子表分裂 • 原则:避免表分裂,及时表合并 • 表分裂的问题 • 在一个集群中,每次表分裂,会导致集群表数量的增加;集群中 表的数量就是路由的条数,表数量越多,路由的效率就会越低 • 一个实例上面的表越多,对该实例运行环境的判断就越复杂:同 一实例上的子表,表现各异,交叉影响的评估难度增大,可能导 致连锁反应 • 扩容:整表迁移 > 子表分裂 • 缩容:子表合并 > 整表搬迁 T1 T2 T3 整表迁移 T21 子表分裂
13. GW(逻辑表)Mysql(物理表) 当SET资源不够 T T 0 或表记录超标 时,触发扩容, 物理表分裂 GW(逻辑表)Mysql(物理表) T 0 T 1 T 2 T T 3 该过程自动完成 T n 初始态:逻辑表=物理表 扩容后:逻辑表=N个物理表
14. • 搬迁策略 • 先切后搬 • 先搬后切 • 搬迁过程 1. 镜像同步 • 源agent:记录日志点,导出T中新号段镜像 • 源agent:向T_d批量插入镜像数据 2. 追日志 • 源agent:向T_d追日志 3. 日志追平 • 源agent:日志相差
15. • 传统的DDL操作A->B • A表加读锁(影响写) • 用A的建表语句创建B,并修改B结构 • 拷贝A数据到B,锁定B,删除A • B rename成A • 刷新数据字典并释放锁 • 新方式 • 直接采用在线迁移的方式完成 a)可以立即返回到业务,实际的迁移操作异步完成 b)整个过程基本上不锁表
16. • group by • Max,sum,min,ave等聚合函数 • Distinct,count(1) • Order by 业务Server 流式收集结果 并排序 gw Select * from T order by f1 limit 10; Select * from limit 10; T_shMardy_S1QoLrder by f1 MySQL Select * from limit 10; T_shaMrdy_3SQorLder by f1
17. 自动切换 主备一致性 自动恢复 跨IDC容灾
18. 谁要切换? 怎么切换? 如何恢复? • 如何发现故障? • 如何保障数据一致性? • 如何重建SET? • 如何确定是否需要切换? • 如何切请求? 监控是基础,一致性是核心
19. zookeeper 检测到A当机,执行选 举w切atc换he流r 程 scheduler 注册成临时节点 Agent A 监控是否可以建立新连接, 可读,可写,可同步,资源 消耗情况 MySQL 实例 Agent B MySQL 实例 Agent C MySQL 实例
20. MySQL 主节点 1.写入undo log 2.更新page cache 3.写redo log 4. trx_prepare日志 5.写入binlog 6.Commit日志 7.Return给客户端 Binlog文件 !!!给了 MySQL 备节点 业务应答, 但是binlog 可能没有被 同步到备机, 导致事务丢 Sql线程apply relay log Slav失e的io线程读取binlog Relay log文 件 Binlog文件
21. MySQL 主节点 1.写入undo log 2.更新page cache 3.写redo log 4. trx_prepare日志 5.写入binlog 6.Wait ack 6.Commit日志 7.Return给客户端 Binlog文件 !!!给了业 务证收返应b到回in答r应ello答a,yglo能已g 保经 同步到备机的 relay log MySQL 备节点 Sql线程apply relay log Slave的io线程读取binlog Relay log文 件 Binlog文件
22. Commit VS 异步复制 User thread SQL Parse 半同步复制 Commit User thread SQL Parse Storage Involve Storage Involve Write binlog Write binlog Waiting slave dump Storage commit Storage commit Commit完成 Return to client Commit完成 Return to client 半同步复制可保障一致性,但是…
23. • 1.超时后蜕化成异步,金融场景不合适 • 2.跨IDC的情况下性能不乐观 主备复制方案(跨IDC) 异步 半同步 网易innosql(半同步) MariaDB Galera Cluster TPS 20,000 2,200 4,500 6,000 时耗(ms) <10 4~600 4~500 4~10000
25. User Thread Commit(T1w)rite Commit(T2) User ACK Thread Dump Thread Dump ACK Thread 保存 Binlog read Send Transaction(T1) with ACK request THD 回话 Send T2 IO Thread SQL Thread write relaylo g read OK(T1) 返回应答 Engine commit Inform(T1) ACK(T1) master 主备复制方案(跨 IDC) 异步 半同步 异步化改造后的半 同步 网易innosql(半同 slave TPS 20,000 2,200 9,500 时耗(ms) <10 4~600ms 99.9%的<30ms,少量毛刺,最大达 到600
26. 原则: 1、主机可读可写,备机只读,备机可以开放给业务查询使用 2、任何时刻同一个SET不能有两个主机 3, 宁愿拒绝服务,不提供错误的服务,追求CAP中的C,必要的时候牺牲部分A Scheduler Scheduler Agent Agent Proxy Master DB Slave 1 Agent Slave 2 Agent Agent Proxy Slave 3 Master Agent 6 Slave 2 SET 1、主DB降级为备机(杀死当前所有session,设置只读, 如因为当机原因没有收到下次重新启动也会执行这个 流程),同时会给网关下发暂时没有主节点的路由 2、参与选举的备机停止io线程之后上报最新的binlog点 3、scheduler收到binlog点之后,选择出binlog最大的 节点(可能同时有2个)并要求对应的机器加载完relay log。当收到加载完relay log信息之后,则选择这个 应答的节点为主机; SET 4、重建主备关系 5、修改路由 6、请求发给新的主机
27. A(主) a+1,a+2,a+3 B(备) a+1 C(备) a+1,a+2 A当机,C选举 成新的主机 C(主) a+1,a+2,c+1,c+2 B(备) a+1,a+2,c+1,c+2 回退事务a+3 A(备) a+1,a+2,a+3,c+ 1,c+2 重新加入,可 能需要回退部 分事务 C(主) a+1,a+2,c+1,c+2 B(备) a+1,a+2,c+1,c+2 B(备) a+1 C(主) a+1,a+2,c+1,c+2 Xtraback up自动快 速重做 D(备) …
28. • TDSQL当前定位是支撑OLTP类型短事务的业务,不支持join操作 • 弱化了单机MySQL的功能,如存储过程,触发器,视图,自增序列号, Session变量等 • 业务可以将它看成一个加强版的NoSQL系统,优势是存储的是结构化 数据,支持SQL操作 ,支持多个索引,数据高一致性访问,持久化非 常强,数据自动扩容等 • 所有的表能通过某个shard字段(如QQ号,微信号等)进行数据水平拆 分,高频的SQL操作都能带上这个shard字段
29. • 按组扩容 拥有同样shard字段的所有表采用同样的路由规则,以支持同一 个shard下所有的sql操作,如join,事务等 • 集群虚拟化 引入docker来更灵活地管理set和节点,加强资源隔离
31. Q&A
33. 热烈欢迎各位大牛加入 微信:harlylei Email: harly@vip.qq.com