关注腾讯云开发者，一手技术干货提前解锁👇
01
背景
02
如何用好数据库如何扩展数据库的读写性能？- 规格扩容（垂直扩展），本机资源不足导致跨机扩容，耗时久，需要数小时：因物理机架构下，数据存储在本台机器，在实例进行规格的扩容，但是本机资源不足的情况，需要将实例迁移到其他资源充足的机器，数据需要迁移到目标机器，数据量越大，跨机器数据复制耗时越久；
- 添加只读节点（横向扩展），耗时久，需要数小时：物理机架构下，每个实例的节点都有独立的数据存储，当添加新节点时，需要将主节点的数据复制到新的节点。常规情况下，需要满足容灾部署模型（节点的反亲和性控制策略），一个数据库实例的 主节点、只读节点、从节点 不允许分布到同一台物理机器，所以添加只读节点会涉及跨机器的数据复制，数据量越大耗时越久；
- 每个节点独立提供服务，可能因业务流量不均，部分节点负载高，部分节点负载很低，资源无法有效利用；
- 一个只读节点故障会直接影响业务访问，高可用能力不足；
- 多个节点在查询同一条记录时，可能由于主从复制延迟的差别，数据在多个节点上的更新时间有先有后，导致业务在多个节点同时读取到的数据不一致，可能对某些敏感业务不友好；
- 事务内有大量读请求需要直接访问主节点，主节点的负载压力大；
一致性策略，满足不同场景对数据的一致性访问诉求
03
事务拆分，进一步提升写性能事务写前拆分
04
如何构建容灾？- 从数据库实例部署维度：
- 机器级故障：主从均部署在同可用区，可以应对可用区内机器故障等场景，但面对大规模的可用区级别故障场景，无法恢复。但相比跨可用区的部署结构，主从的网络延迟更低；
- 可用区级故障：基于物理机架构的产品形态，常规场景两节点跨可用区，针对金融场景可使用三节点的跨可用区；
- 地域级故障：构建跨地域的灾备集群；
- 云级别故障：基于 IDC+云厂商 或者 A 云厂商 + B 云厂商的跨云容灾；
- 从数据安全性的维度，提供不同维度的的安全能力，在极端故障场景，保障业务可以基于备份数据进行恢复
- 数据备份：常规情况下，默认的数据备份会存储在主实例的同可用区；可依据数据的敏感度，备份时长可自由设定，例如有部分敏感客户会讲敏感数据备份3年；
- 跨地域备份：备份数据的跨地域存放，在出现地域级别的场景下，可以基于异地的备份恢复；
- 由于恢复需要基于备份导入数据到实例，恢复耗时相比跨地域的灾备集群模式会大大增加；
- 可能会丢失部分未来得及备份的数据。
- 多云网络互联互通，在单云的架构下，网络环境由云商负责提供。引入多云后需要协调云商，解决连通性问题；
- 业务层流量调度，需要解决业务层流量调度问题，由 A 云进入的流量要在 A 云闭环，只有在 A 云业务层有故障的时候才会跨云调用；
- 多云异构可观测，需要屏蔽不同云商监控的区别，在上层构建统一的可观测系统；
- 数据层跨云容灾建设，在业务没有完成单元化之前，只要做多云多活数据层的多活/容灾就是需要解决的难题，方案也会比较复杂，这里涉及数据同步、仲裁中心、业务切换、数据补偿等问题。
05
如何提升业务连续性，屏蔽数据库的抖动？连接保持（防闪断）- 计划内：数据库的常规运维操作，包含常规的版本升级、参数变更触发的主节点重启、跨机器的规格扩容、容灾演练触发的人工主备切换等；
- 计划外：数据库组件异常引发的被动切换，例如主节点异常重启、主节点不可用触发的主从切换等。
- 实时性差，往往需要 T+1 以上的时间周期；
- 两份存储成本高，OLTP、OLAP 各一份；
- 管理流程负载，需要经过ETL复杂的过滤、清晰、转换、存储等流程；以及考虑面对大流量的场景下，会引入消息队列进行系统解耦，进一步增加系统复杂度；
