找个代理来转发！读写分离，快速拓展，轻松应对高并发

客户实践及应用：降低运维成本、提升数据安全 王飞跃银行数据库运维工程师 云数据库在银行业务中的应用 私有云，跑批、交易等核心业务公有云，APP商城、社区、服务等非核心业务 什么是数据库代理？ 数据库代理是一种位于应用程序和数据库之间的中间件，用于管理和优化数据库访问和查询。它负责处理所有与数 据库的交互，包括连接管理、查询优化、负载均衡、缓存、安全性和监控等功能。 通过使用数据库代理，可以提高数据库的性能、可伸缩性和可靠性，同时减少应用程序开发和维护的工作量。 功能 自动读写分离&负载均衡 地址1 读/写 读/写 地址2 只读实例 只读实例 主实例 自动读写分离 •自助读写分离，统一访问地址 •原生链路支持，提升性能，减少维护成本 •故障转移：即使数据库代理故障请求也能正常访问主库 •扩展自由：主实例发生切换、变配、 只读实例增减等情况，数据库代理可动态热加载配置，不会出现网络中断或重启 负载均衡 •可根据业务情况设置权重和阈值 功能 防闪断 防闪断 在运维过程中，总会根据需要进行相应的调整，如变更配置、计划内HA切换、计划内重启等，这些行为可能会中断用户会话，导致连接闪断、新建连接短暂失败等问题。云数据库MySQL数据库代理提供防闪断能力，在数据库实例进行有损切换、转移时，可以提供无损的应用连续性，避免连接和事务的中断。 感谢观看！ Thankyou 数据库代理实践：有效管理负载均衡、故障转移 目录Menu ·为什么需要数据库代理 ·数据库代理架构设计与最佳实践 为什么需要数据库代理 我们申请了一个数据库 cdb-readwrite 4C8G 192.168.1.1:3306 defmysql_query(sql): conn=mysql_connect(READWRITE_DB)conn.execute(sql) returnconn.fetch() 为什么需要数据库代理 读请求量有些大，我们又申请了一个只读节点 cdb-readwrite 4C8G 192.168.1.1:3306 defmysql_query(sql,db_type='readwrite'):ifdb_type=='readwrte': conn=mysql_connect(READWRITE_DB) cdb-readonly 4C8G 192.168.1.2:3306 else: conn=mysql_connect(READONLY_DB)conn.execute(sql) returnconn.fetch() 为什么需要数据库代理 业务量增大，我们申请了第二个只读实例。 1.第二个只读实例规格更大，所以需要把更多请求发过去。 2.当只读实例发生延迟或宕机的时候，需要把请求发送到延迟低的健康实例上。 3.对于短连接请求，需要实现一个连接池避免频繁建连的影响。 4.升级数据库会触发连接闪断，我们需要业务对闪断无感知。 cdb-readwrite 4C8G 192.168.1.1:3306 cdb-readonly 4C8G 192.168.1.2:3306 cdb-readonly-2 16C32G 192.168.1.3:3306 ？ 数据库代理的优势 ·功能丰富：读写分离、负载均衡、连接池等 ·高可用：支持后端数据库透明切换，无感升降配 ·开箱即用：无需业务改造适配 数据库代理架构设计 VPCIP 192.168.1.4:3306 proxy-node-14C8Gproxy-node-24C8G cdb-readwrite4C8G 192.168.1.1:3306 cdb-readonly4C8G 192.168.1.2:3306 cdb-readonly-216C32G 192.168.1.3:3306 读写分离负载均衡 proxy WRITEREAD weight:4 weight:0 weight:4weight:16 cdb-readwrite4C8G 192.168.1.1:3306 cdb-readonly4C8G 192.168.1.2:3306 cdb-readonly-216C32G 192.168.1.3:3306 延迟剔除 proxy 复制延迟阈值:30 WRITEREAD cdb-readwrite4C8G 192.168.1.1:3306 cdb-readonly4C8G 192.168.1.2:3306 cdb-readonly-216C32G 192.168.1.3:3306 复制延迟:35复制延迟:0 延迟剔除最小保留数 proxy 复制延迟阈值:30 WRITE READ cdb-readwrite4C8G 192.168.1.1:3306 cdb-readonly4C8G 192.168.1.2:3306 cdb-readonly-216C32G 192.168.1.3:3306 复制延迟:45复制延迟:35 延迟剔除最小保留数 WRITE proxy READ 复制延迟阈值:30最小保留数:1 cdb-readwrite4C8G 192.168.1.1:3306 cdb-readonly4C8G 192.168.1.2:3306 cdb-readonly-216C32G 192.168.1.3:3306 复制延迟:45复制延迟:35 高可用 ·代理高可用：无状态计算节点，多节点保证高可用 ·数据库高可用：后端数据库的切换对客户端无感 ·整体架构高可用：多可用区容灾 数据库代理高可用 proxy-node-1 HAagent proxy-node-2 HAagent proxy-node-2 心跳上报 拨测探活 x 快速拉起 管控系统 后端数据库高可用 管控系统 1通知proxy开始切换 6通知proxy连接新主节点 4管控确认旧节点无连接后开始切换 Client Proxy 2proxy断开旧主连接 X OldRW 5管控提升新主节点 3Proxy阻塞Client请求并暂存 7proxy向新主节点建连，重建会话状态，并发送暂存语句 连接状态保持 未提交事务 系统/用户变量 预编译语句 临时表/锁/其他 等待状态消除 等待语句关闭 通过语句重放 等待事务提交 NewRW 高可用-跨可用区 cvm-gz1 cvm-gz2 VPCIP 192.168.1.4:3306 proxy-node-1 proxy-node-2 proxy-node-3 proxy-node-4 cdb-readwrite cdb-readonly cdb-readonly-2 感谢观看！ Thankyou 向着云原生进化 --集群新架构助力企业轻松应对高并发 目录Menu ·为什么我们需要新架构 ·集群版（基于新架构的全新形态） ·集群架构RoadMap 导师介绍 程昌明 腾讯云数据库 高级产品经理 腾讯云数据库MySQL产品线负责人，在高可 用解决方案、信息安全、系统规划、性能优化、灾难恢复与信息系统整合方面拥有丰富的实践经验。曾为网络运营商、银行、能源（国网、南网）及政府等各行业的关键业务系统，提供运维、升级、项目实施与管理、容灾建设等疑难问题咨询与技术实施服务。 为什么我们需要新架构 存算一体化架构 VIP1# 只读（在线） VIP0# 读写 VIP2# (全局读写分离) VIP3# 只读（离线） VIP5# TGW（R） TGW（W/R） proxy TGW（R） TGW（R） 上海二区 Master 异步、半同步、强同步 replication Slave0# 广州四区 灾备实例master 异步、半同步、强同步 replication 灾备实例slave replication RO0# RO1# RO2# RO3# RO0# RO1# RO2# RO3# 上海五区 Slave1# 冷备/binlog备份中心 RO4# RO5# RO6# 优势： •本地磁盘极低IO响应时间 •本地资源无损弹性（CPU弹性） •网络架构易扩展 劣势： •备份恢复时长随数据量增长 •磁盘规格受限 •计算资源上限受代次限制 •需要不可读备机提供可用性保障 •底层内核特性更新缓慢 集群版架构 COMPUTE COMPUTE COMPUTE Slave BinLog Master BinLog Slave Write（Atomic） Read（I/Ouring） 特点： •计算资源与磁盘规格无需绑定 •支持全部性能级别磁盘类型 •计算资源按照算力定期迭代 •备份使用云盘快照 STORAGE cell cellCloudDisk cell cellCloudDisk cell cellCloudDisk 快照存储中心 •适用于新架构的内核优化 •快速增删节点 •支持高频快照（15分钟间隔） 场景： •业务变化较大，频繁扩缩容或增加只读实例提升读性能 •经常需要快速回档的游戏项目 •数据量较大的在线业务系统 横向&纵向扩容 512核，2TB内存 读写节点 只读节点 只读节点 只读实例 只读实例 纵向上限高： •CPU最大支持512核 •内存最大支持2TB •存储最大支持32TB （预计年底支持64TB） 横向扩容快： •5分钟快速扩展 •支持独立只读 •支持自动读写分离 •支持自动故障转移 只读节点扩展 集群版 节点重建后bufferpool预热，防止业务抖动 after data Bufferpool before data Bufferpool HA 主备缓存同步优化 snapshot HotpagesPagesneedwarmup 内核特性–BP预热 背景及问题 •节点重建或常态化的实例迁移，新节点BufferPool需要长时间预热，而预热期间影响业务运行，QPS长达数十分钟恢复正常。 •主从缓存不同：读写节点业务与只读节点业务缓存数据存在差异。 解决方案-主从缓存同步优化 •主库异步dumpbufferpool信息，获取Btree热点数据范围，生成逻辑快照。 Snapshottherangeofhotpages dump master Bufferpool slave Bufferpool load Scantherangehotpages •从库加载快照信息，通过直接扫描Btree异步预热备库bufferpool。 •主从bufferpool热数据逻辑保持一致。 64并发下oltp_write_only场景测试结果 内核特性–原子写 背景及问题 •MySQLInnoDB的pagesize一般为16KB，数据校验也是按16KB页面来计算的。但操作系统写入磁盘是以4KB页进行的，为了保证InnoDB的16KB页的原子写入，MySQL采用DoubleWrite的方式完成数据写入，数据页面存在双倍的写入。 解决方案-16k原子写 •16k原子写是通过文件系统COW异地更新的机制，确保MySQL16k页面原子写入，优化MySQL的写入性能和数据写入量，解决DoubleWrite带来的额外IO带宽占用问题。 64并发下oltp_read_write场景测试结果 内核优化–提升15%性能 代码段锁定/多备份 ORCunwinder io_uring 网络配置调优 内核占用内存优化 NUMAawarespinlock 200000 180000 性能提升明显 160000 140000 120000 100000 80000 60000 40000 •从实际测试数据观察，对比优化前，在读写混合场景下有30%~50%的性能提升。 测试方案 •使用sysbench工具，在读写混合场景下设定并发度为CPU核数8倍进行测试。 20000 0 2核4G 4核8G 4核16G 8核16G 优化前QPS优化后QPS 8核32G 16核3