2.9 云数据库及最佳实践¶

课程简介¶

数据库是业务系统的核心心脏。本课程将深入讲解腾讯云两大主流关系型数据库——云数据库 MySQL (TencentDB for MySQL) 和云数据库 PostgreSQL 的架构原理、高可用设计及运维最佳实践。我们将重点探讨如何利用云原生的能力构建高可用、高可靠、高扩展的数据库架构。

学习目标¶

通过本课程的学习，您将能够：

✓ 掌握 MySQL 架构：理解主从复制原理、数据同步方式（异步/半同步/强同步）及备份回档机制。
✓ 掌握 PostgreSQL 特性：了解 PG 的地理信息处理（PostGIS）、高可用架构及企业级应用场景。
✓ 实施读写分离：学会通过数据库代理（Database Proxy）实现透明的读写分离，提升系统吞吐量。
✓ 设计高可用容灾：掌握同城双活、两地三中心等数据库容灾架构的设计与部署。

第一部分：云数据库 MySQL (TencentDB for MySQL)¶

本部分导读
腾讯云 MySQL 是基于开源 MySQL 深度优化的高性能数据库服务，广泛应用于互联网、金融、电商等领域。

一、产品概述与核心概念¶

1.1 产品特性¶

完全兼容：100% 兼容 MySQL 协议，无缝迁移现有业务。
极致可靠：提供高达 99.9999999% 的数据可靠性，支持三副本存储。
弹性扩展：支持分钟级扩容 CPU/内存和磁盘。
智能运维：集成 DBbrain 智能诊断工具，提供性能优化建议。

1.2 核心概念 (Key Concepts)¶

实例 (Instance)：独立的数据库资源实体。
只读实例 (Read-Only Instance)：仅处理读请求的单节点实例，用于分担主库读压力。
RO 组 (Read-Only Group)：只读实例的集合，提供统一的 VIP，实现读请求的负载均衡。
灾备实例 (Disaster Recovery Instance)：位于不同地域或可用区的备库，用于异地容灾。
数据库代理 (Database Proxy)：位于应用与数据库中间的网络代理，核心功能是实现读写分离和连接池管理。

二、高可用架构原理¶

2.1 主从架构与数据同步¶

腾讯云 MySQL 默认采用主备（Master-Slave）架构。主节点处理写请求，备节点实时同步数据。

三种数据同步方式对比：

同步方式	原理	优点	缺点/风险	适用场景
异步复制 (Async)	Master 写完 Binlog 即返回成功，不等待 Slave 确认。	性能最高，响应最快。	主库宕机时可能丢失数据（RPO > 0）。	对性能要求极高，允许少量数据丢失的非核心业务。
半同步复制 (Semi-sync)	Master 写完后，等待至少一个 Slave 接收并写入 Relay Log 后才返回成功。	兼顾性能与可靠性。	若 Slave 均不可用，会自动降级为异步复制。	大多数生产环境的默认推荐配置。
强同步复制 (Strong Sync)	Master 必须等待 Slave 确认写入成功后才返回。若 Slave 不可用，主库暂停写操作。	数据零丢失（RPO = 0）。	牺牲可用性换取一致性，Slave 故障会阻塞主库。	金融核心交易系统。

2.2 复制原理¶

Master：开启 Binlog Dump 线程，将二进制日志（Binlog）发送给 Slave。
Slave：
- I/O 线程：接收 Binlog 并写入本地的中继日志（Relay Log）。
- SQL 线程：读取 Relay Log 并重放 SQL 语句，实现数据同步。

三、备份与回档¶

3.1 备份机制¶

物理备份 (全量)：直接拷贝数据库文件（.xb 格式），速度快，恢复效率高。支持自动周期性备份。
逻辑备份 (SQL)：导出 SQL 语句（mysqldump），支持手动触发。
Binlog 备份 (增量)：实时备份 Binlog 日志，用于恢复到任意时间点。

3.2 回档能力 (Flashback)¶

按时间点回档：基于“全量备份 + Binlog”，可将数据库回滚到过去 7 天内的任意秒级时间点。
回收站：误删表（Drop Table）后，表会进入回收站保留一段时间，可一键恢复。
极速回档：利用 CSBS/CBS 快照技术，实现 TB 级数据的快速挂载恢复。

第二部分：云数据库 PostgreSQL¶

本部分导读
PostgreSQL 被誉为“世界上最先进的开源关系型数据库”，在地理信息（GIS）和复杂查询方面表现卓越。

一、产品特性与场景¶

1.1 核心优势¶

插件生态：支持 PostGIS（地理信息）、TimescaleDB（时序数据）等插件。
复杂查询：对 JOIN、复杂 SQL 和 JSON 数据的处理能力优于 MySQL。
高兼容性：支持 Oracle 语法兼容插件，便于去 O 迁移。

1.2 典型应用场景¶

LBS 地理应用：利用 PostGIS 插件存储经纬度、计算距离、圈选范围（如打车、外卖应用）。
企业核心系统：ERP、CRM 等复杂业务逻辑系统，利用 PG 强大的存储过程和事务控制。
数据仓库：支持海量数据分析和复杂聚合查询。

二、架构与备份¶

2.1 高可用架构¶

支持 一主一从 或 一主多从。
采用流复制（Streaming Replication）技术，支持同步和异步模式。

2.2 备份策略¶

全量备份：物理备份，支持压缩（压缩比约 30%）。
增量备份：WAL 日志备份（Write-Ahead Logging）。
克隆实例：支持按时间点克隆出一个新实例，用于测试或数据校验。

第三部分：云数据库最佳实践¶

场景一：读写分离 (Read/Write Splitting)¶

背景：电商大促或社交应用中，读请求（查询商品/看动态）远多于写请求（下单/发动态），主库压力巨大。

解决方案：数据库代理 (DB Proxy)

架构设计：
- 购买 1 个主实例 + N 个只读实例。
- 开通数据库代理，获得一个统一的读写分离地址。
工作流程：
- 应用连接 Proxy 地址。
- Proxy 自动识别 SQL 类型：
  - 写请求 (INSERT/UPDATE) -> 转发给 主实例。
  - 读请求 (SELECT) -> 负载均衡分发给 只读实例。
最佳配置：
- 自动加入：开启“新购只读实例自动添加到代理”，扩容更便捷。
- 故障剔除：当只读实例故障或延迟过高时，Proxy 会自动将其剔除，保障业务读取不报错。
- 读权重：通常选择“系统自动分配”，根据实例规格自动加权。

场景二：两地三中心容灾 (Geo-Disaster Recovery)¶

背景：金融级业务要求能够抵御城市级灾难（如地震、光纤挖断）。

架构设计：

graph TD
    subgraph 地域A_同城双中心
        AZ1[机房 A (主中心)]
        AZ2[机房 B (同城灾备)]

        Master[主实例] -- 强同步/半同步 --> Slave_Local[同城备实例]
    end

    subgraph 地域B_异地灾备
        AZ3[机房 C (异地中心)]
        Slave_Remote[异地灾备实例]
    end

    Master -- 异步复制 --> Slave_Remote

同城双活：
- 在地域 A 的机房 A（主）和机房 B（备）部署主备实例。
- 采用强同步或半同步复制，确保 RPO=0（数据不丢）。
- 正常情况下，读写流量在机房 A，故障时自动秒级切换到机房 B。
异地灾备：
- 在地域 B（如上海）部署灾备实例。
- 通过DTS或原生复制跨地域同步数据（通常为异步）。
- 作用：当地域 A 发生毁灭性灾难时，手动激活地域 B 的实例接管业务。

场景三：性能压测与选型¶

在上线前，建议使用工具对数据库进行基准测试，确保存储 I/O 满足需求。 - 工具：Sysbench, TPCC. - 关键指标：TPS (每秒事务数), QPS (每秒查询数), Latency (延迟). - 存储选型：对于 I/O 密集型业务，务必选择 SSD 云硬盘 或 增强型 SSD。

课程总结¶

知识点回顾¶

MySQL 同步：半同步复制是生产环境平衡性能与安全的最优解。
PG 优势：处理 GIS 数据和复杂 SQL 首选 PostgreSQL。
读写分离：通过数据库代理（Proxy）实现透明的读流量分担，无需修改代码。
容灾层级：同城双中心（高可用） > 异地灾备（高可靠）。

架构师实践清单 (Checklist)¶

[ ] 数据安全：生产库是否开启了自动备份？Binlog 是否保留至少 7 天？
[ ] 高可用：主备实例是否分布在不同的可用区？
[ ] 性能优化：读多写少的业务是否开启了读写分离？
[ ] 监控告警：是否配置了 CPU、磁盘空间、主从延迟的告警？
[ ] 容灾演练：是否定期进行灾备切换演练，验证 RTO/RPO？

本章课程到此结束。下一章，我们将深入分布式数据库领域，讲解 2.10 企业级分布式数据库 TDSQL 及最佳实践。