Tencent Cloud

Recent Pages

系统架构

最后更新时间：2024-01-11 11:07:58
架构简介
高可用架构
在生产系统中，通常都需要用高可用方案来保证系统不间断运行，数据库作为系统数据存储和服务的核心能力，其可用要求高于计算服务资源。目前，数据库的高可用方案通常是让多个数据库服务协同工作，当一台数据库故障，余下的立即顶替上去工作，这样就可做到不中断服务或只中断很短时间；或者是让多台数据库同时提供服务，用户可以访问任意一台数据库，当其中一台数据库故障，立即更换访问另外数据库即可。
由于数据库中记录了数据，想要在多台数据库中切换，数据必须是同步的，所以数据同步技术是数据库高可用方案的基础。当前，数据复制有以下三种方式：
异步复制：应用发起更新（含增加、删除、修改操作）请求，Master 完成相应操作后立即响应应用，Master 向 Slave 异步复制数据。因此异步复制方式下，Slave 不可用不影响主库上的操作，而 Master 不可用有概率会引起数据不一致。
强同步复制：应用发起更新请求，Master 完成操作后向 Slave 复制数据，Slave 接收到数据后向 Master 返回成功信息，Master 接到 Slave 的反馈后再应答给应用。Master 向 Slave 复制数据是同步进行的，因此 Slave 不可用会影响 Master 上的操作，而 Master 不可用不会引起数据不一致。
注意：
使用“强同步”复制时，如果主库与备库之间网络中断或备库出现问题，主库也会被锁住（hang），而此时如果只有一个主库或一个备库，那么是无法做高可用方案的。因为单一服务器服务，如果故障会直接导致部分数据完全丢失，不符合金融级数据安全要求。
半同步复制：半同步复制是 google 提出的一种同步方案，其原理是正常情况下数据复制方式采用强同步复制方式，当 Master 向 Slave 复制数据出现异常的时候（Slave 不可用或者双节点间的网络异常）退化成异步复制。当异常恢复后，异步复制会恢复成强同步复制。半同步复制意味着 Master 不可用会有较小概率引起数据不一致。
常见高可用架构
共享存储方案：使用共享存储，如 SAN 存储。SAN 的原理是多台数据库服务器共享同一个存储区域，这样多台数据库都可以“读写”同一份数据。当主库发生故障时，第三方高可用软件把文件系统在备库上挂起，然后在备库上启动数据库即完成切换。
日志同步或流复制同步：数据库最常见复制模式，如 MySQL 数据库。每当写入数据，MySQL Master Server 将自己的 Binary Log 通过复制线程传输给 Slave，Slave 接收到 Binary Log 以后，依照 Binary Log 内容，写入相同数据到文件系统。目前 MySQL 已经提供：
异步复制：异步复制可以确保得到快速的响应结构，但是不能确保二进制日志确实到达了 Slave 上，即无法保障数据一致性。
半同步复制：（由 google 提供的同步插件）半同步复制对于客户的请求响应稍微慢点，在超时等情况下，会退化为异步，即基本保障数据一致性，但无法保证数据完全一致性。
基于触发器的同步：使用触发器记录数据变化，然后同步到另一台数据库上。
基于中间件的同步：系统不直接连接到底层数据库，而是连接到一个中间件，中间件把数据库变更发送到底层多台数据库上，从而完成数据同步。早几年，由于业务需求，数据库性能、同步机制等问题，某些软件开发商通常采用类似架构。
MariaDB 架构简介
异步多线程强同步复制技术
同步技术发展过程中，提供了异步复制、半同步等同步技术，这两种技术面向普通用户群体，在用户要求不高、网络条件较好、性能压力不大的情况下，能够基本保障数据同步；但通常情况下，采用异步复制、半同步机制容易经常出现数据不一致问题，直接影响系统可靠性，甚至出现丢失交易数据，带来直接或间接经济损失。
腾讯云业务经过多年积累，自主研发出数据库异步多线程强同步复制方案（Multi-thread Asynchronous Replication，MAR），相比于 Oracle 的 NDB 引擎、Percona XtraDB Cluster 和 MariaDB Galera Cluster，其性能、效率和适用性更具优势。MAR 强同步方案特点如下：
一致性的同步复制，保证节点间数据强一致性。
对业务层面完全透明，业务层面无需做读写分离或同步强化工作。
将串行同步线程异步化，引入线程池能力，大幅度提高性能。
支持集群架构。
支持自动成员控制，故障节点自动从集群中移除。
支持自动节点加入，无需人工干预。
每个节点都包含完整的数据副本，可以随时切换。
无需共享存储设备。
腾讯 MAR 方案强同步技术，只有当备机数据同步后，才由主机向应用返回事务应答，示意图如下：
﻿

从性能上优于其他主流同步方案，通过对比，在跨可用区( IDC 机房)同样的测试方案下，我们发现其 MAR 技术性能优于 MySQL 半同步约5倍，优于 MariaDB Galera Cluster 性能1.5倍（此处测试使用 sysbench 标准用例测试）。
﻿
集群架构
MariaDB 采用集群架构，一套独立 MariaDB 系统至少需要十余系统或组件组成，架构简图如下：
﻿

其中，MariaDB 最核心的三个主要模块是：决策调度集群（Tschedule）、数据库节点组（SET）和接入网关集群（TProxy），三个模块的交互都是通过配置集群（TzooKeeper）完成。
﻿
数据库节点组（SET）：由兼容 MySQL 数据库的引擎、监控和信息采集（Tagent）组成， 其架构有“一个主节点（Master）、若干备节点（Slave_n）、若干异地备份节点（Watcher_m）”，通常情况下：
部署在跨机架、跨机房的服务器中。
通过心跳监控和信息采集模块（Tagent）监控，确保集群的健壮性。
分布式架构下，基于水平拆分，若干个分片（数据库节点组）提供一个“逻辑统一，物理分散”分布式的数据库实例。
决策调度集群（Tschedule）：作为集群的管理调度中心，主要管理 SET 的正常运行，记录并分发数据库全局配置，其包括：
调度作业集群（MariaDB Scheduler）：帮助数据库管理员或者数据库用户自动调度和运行各种类型的作业，例如数据库备份、收集监控、生成各种报表或者执行业务流程等，MariaDB 把 Schedule、zookeeper、OSS（运营支撑系统）结合起来通过时间窗口激活指定的资源计划，完成数据库在资源管理和作业调度上的各种复杂需求，Oracle 也用 DBMS_SCHEDULER 支持类似的能力。
程序协调与配置集群（TzooKeeper）：它为 MariaDB 提供配置维护、选举决策、路由同步等，并能支撑数据库节点组（分片）的创建、删除、替换等工作，并统一下发和调度所有 DDL（数据库模式定义语言）操作，TzooKeeper 部署数量需大于等于三台。
运维支撑系统（OSS）：基于 MariaDB 定制开发的一套综合的业务运营和管理平台，同时也是真正融合了数据库管理特点，将网络管理、系统管理、监控服务有机整合在一起。
决策调度集群独立部署在腾讯云全国三大机房中（跨机房部署，异地容灾）。
接入网关集群（TProxy）：在网络层连接管理 SQL 解析、分配路由（TProxy 非腾讯云网关 TGW）。
与数据库引擎部署数量相同，分担负载并实现容灾。
从配置集群（TzooKeeper）拉取数据库节点（分片）状态，提供分片路由，实现透明读写。
记录并监控 SQL 执行信息，分析 SQL 执行效率，记录并监控用户接入信息，进行安全性鉴权，阻断风险操作。
TProxy 前端部署为腾讯网关系统 TGW，对用户提供唯一一个虚拟 IP 服务。
这种集群架构极大简化了各个节点之间的通信机制，也简化了对于硬件的需求，这就意味着即使是简单的 x86 服务器，也可以搭建出类似于小型机、共享存储等一样稳定可靠的数据库。