印刻数据库

外观

MariaDB 架构设计最佳实践 ​

架构设计是数据库系统的基础，直接影响系统的性能、可用性、可扩展性和维护成本。一个合理的架构设计能够有效支撑业务发展，同时降低运维复杂度。

架构设计原则 ​

1. 业务驱动原则 ​

架构设计必须以业务需求为核心，不同的业务场景需要不同的架构方案：

  • 事务型业务：优先考虑数据一致性和高可用性
  • 分析型业务：优先考虑查询性能和数据处理能力
  • 混合业务：考虑读写分离或数仓架构

2. 高可用原则 ​

  • 避免单点故障
  • 设计合理的故障切换机制
  • 确保数据冗余和可恢复性
  • 定期进行灾备演练

3. 可扩展性原则 ​

  • 垂直扩展：通过升级硬件提升性能
  • 水平扩展：通过增加节点提升处理能力
  • 读写分离：分离读流量和写流量
  • 分库分表：将大表拆分为小表，分散存储压力

4. 性能优化原则 ​

  • 合理设计数据库结构
  • 优化索引和查询语句
  • 选择合适的存储引擎
  • 配置优化的参数

5. 安全性原则 ​

  • 数据加密（传输加密、存储加密）
  • 严格的权限管理
  • 定期安全审计
  • 漏洞修复和补丁管理

6. 可维护性原则 ​

  • 清晰的架构文档
  • 标准化的部署流程
  • 完善的监控体系
  • 自动化运维工具

不同业务场景的架构选择 ​

小型应用（日活 < 10万） ​

特点：

  • 数据量小（< 100GB）
  • 并发请求低（< 1000 QPS）
  • 业务逻辑简单

推荐架构：

  • 单机 MariaDB 实例
  • 定期备份策略
  • 基本监控告警

版本建议：

  • MariaDB 10.3+（长期支持版本）

配置示例：

ini
# my.cnf 配置
[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
max_connections = 500
query_cache_type = 0  # MariaDB 10.1+ 建议关闭

中型应用（日活 10万 - 100万） ​

特点：

  • 数据量中等（100GB - 1TB）
  • 并发请求中等（1000 - 5000 QPS）
  • 有一定的高可用需求

推荐架构：

  • 主从复制架构（1主1从或1主2从）
  • 读写分离（可选）
  • 定期备份 + 实时复制
  • 完善的监控体系

版本建议：

  • MariaDB 10.4+（支持更多高可用特性）

架构示意图：

应用层 → 连接池 → 主库（写操作）
           ↓
         从库（读操作）

大型应用/高并发场景（日活 100万 - 1000万） ​

特点：

  • 数据量大（1TB - 10TB）
  • 并发请求高（5000 - 50000 QPS）
  • 高可用要求严格（RTO < 5分钟，RPO < 1分钟）

推荐架构：

  • 主从复制 + 读写分离：主库处理写请求，多个从库处理读请求
  • Galera Cluster：多主架构，提供更高的可用性和扩展性
  • 负载均衡：使用 ProxySQL 或 MaxScale 进行读写分离和负载均衡
  • 分库分表：对大表进行拆分，分散存储和查询压力
  • 缓存层：使用 Redis 等缓存减轻数据库压力

版本建议：

  • MariaDB 10.5+（支持 Galera Cluster 4.0，性能更好）

架构示意图：

应用层 → 连接池 → 负载均衡（ProxySQL/MaxScale）→ 主库集群（写操作）
                       ↓
                     从库集群（读操作）

超大规模应用（日活 > 1000万） ​

特点：

  • 数据量极大（> 10TB）
  • 并发请求极高（> 50000 QPS）
  • 全球分布用户

推荐架构：

  • 多区域部署：在不同地域部署数据库集群
  • 分库分表：水平拆分和垂直拆分结合
  • 分布式架构：使用 MariaDB Xpand 或结合其他分布式数据库
  • 数据分片：根据业务规则将数据分布到不同节点
  • 边缘计算：在靠近用户的边缘节点处理部分请求

版本建议：

  • MariaDB 10.6+（支持更多分布式特性）
  • MariaDB Xpand（分布式 NewSQL 数据库）

高可用架构设计 ​

主从复制架构 ​

架构说明：

  • 一个主库负责写操作，多个从库负责读操作
  • 从库通过复制机制同步主库数据
  • 支持异步复制、半同步复制和增强半同步复制

版本差异：

  • MariaDB 10.0+ 支持 GTID（全局事务标识符）
  • MariaDB 10.1+ 支持增强半同步复制
  • MariaDB 10.3+ 支持多源复制

最佳实践：

  1. 复制模式选择：

    • 对数据一致性要求高的场景：使用增强半同步复制
    • 对性能要求高的场景：使用异步复制

  2. 从库数量：

    • 建议 2-5 个从库，过多从库会增加主库负担
    • 根据读流量需求调整从库数量

  3. 监控与告警：

    • 监控复制延迟（Seconds_Behind_Master）
    • 设置复制延迟告警阈值
    • 监控主从状态（Slave_IO_Running, Slave_SQL_Running）

  4. 故障切换：

    • 手动切换：使用 STOP SLAVE, RESET MASTER 等命令
    • 自动切换：使用 MHA（Master High Availability）或 Orchestrator

配置示例：

ini
# 主库配置
[mysqld]
server-id = 1
binlog_format = ROW
binlog_row_image = FULL
enforce_gtid_consistency = ON
gtid_mode = ON

sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

# 从库配置
[mysqld]
server-id = 2
enforce_gtid_consistency = ON
gtid_mode = ON

# 启用增强半同步复制（需要安装插件）
plugin_load_add = semisync_master.so
semisync_master_enabled = 1
semisync_master_timeout = 10000

Galera Cluster 架构 ​

架构说明：

  • 多主架构，所有节点均可读写
  • 同步复制，数据强一致性
  • 自动故障检测和恢复
  • 支持节点弹性扩展

版本差异：

  • Galera Cluster 3.x：支持 MariaDB 10.0 - 10.3
  • Galera Cluster 4.x：支持 MariaDB 10.4+，性能和可靠性更好

最佳实践：

  1. 集群规模：

    • 建议 3-9 个节点
    • 奇数节点（避免脑裂）
    • 每个节点配置相同

  2. 网络配置：

    • 使用专用网络进行 Galera 通信
    • 配置合适的 wsrep_slave_threads（根据 CPU 核心数）
    • 调整 wsrep_max_ws_rows 和 wsrep_max_ws_size

  3. 存储配置：

    • 建议使用 SSD 存储
    • 配置 innodb_flush_log_at_trx_commit = 2（平衡性能和可靠性）
    • 关闭 innodb_doublewrite（Galera 已提供类似功能）

  4. 监控与告警：

    • 监控 wsrep_cluster_status（集群状态）
    • 监控 wsrep_local_state_comment（节点状态）
    • 监控 wsrep_flow_control_paused（流控状态）
    • 监控 wsrep_last_committed（事务提交情况）

配置示例：

ini
[mysqld]
# 基础配置
server-id = 1
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 2
innodb_doublewrite = 0

# Galera 配置
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "mariadb_cluster"
wsrep_cluster_address = "gcomm://192.168.1.101,192.168.1.102,192.168.1.103"
wsrep_node_name = "node1"
wsrep_node_address = "192.168.1.101"
wsrep_slave_threads = 8
wsrep_max_ws_rows = 131072
wsrep_max_ws_size = 1073741824
wsrep_sync_wait = 0

MariaDB Cluster (NDB) 架构 ​

架构说明：

  • 基于 MySQL Cluster (NDB) 存储引擎
  • 内存数据库，适合低延迟场景
  • 自动分片和高可用
  • 支持事务和 ACID 特性

版本差异：

  • MariaDB 10.0+ 支持 NDB 存储引擎
  • MariaDB 10.3+ 支持 NDB 7.5
  • MariaDB 10.5+ 支持 NDB 7.6

最佳实践：

  1. 适用场景：

    • 低延迟应用（< 1ms 响应时间）
    • 高并发写入场景
    • 数据量适中（< 500GB）

  2. 节点配置：

    • 至少 2 个管理节点（Mgmd）
    • 至少 2 个数据节点（NDB）
    • 多个 SQL 节点（MariaDB 服务器）

  3. 内存配置：

    • 数据节点内存大小根据数据量确定
    • 配置合适的 ndb_buffer_pool_size
    • 考虑数据压缩以节省内存

  4. 监控与告警：

    • 监控 NDB 集群状态
    • 监控数据节点内存使用情况
    • 监控事务响应时间

读写分离架构 ​

架构说明：

  • 将读请求和写请求分离到不同的数据库节点
  • 主库处理写请求，从库处理读请求
  • 提高系统整体吞吐量
  • 减轻主库负担

实现方式：

  1. 应用层读写分离：

    • 在应用代码中区分读操作和写操作
    • 配置不同的数据库连接池
    • 优点：灵活，性能好
    • 缺点：耦合度高，维护复杂

  2. 中间件读写分离：

    • 使用 ProxySQL、MaxScale 或 MySQL Router 等中间件
    • 中间件自动路由请求
    • 优点：解耦应用和数据库，易维护
    • 缺点：增加系统复杂度和延迟

最佳实践：

  1. 中间件选择：

    • ProxySQL：功能强大，支持查询缓存、读写分离、负载均衡
    • MaxScale：MariaDB 官方中间件，对 Galera Cluster 支持好
    • MySQL Router：Oracle 官方中间件，适合 MySQL 迁移场景

  2. 连接池配置：

    • 合理设置连接池大小
    • 配置连接超时和空闲超时
    • 监控连接池使用情况

  3. 数据一致性处理：

    • 写操作后读操作延迟（强制读主库）
    • 使用 GTID 确保从库同步状态
    • 配置中间件的一致性级别

  4. 监控与告警：

    • 监控中间件性能指标
    • 监控读写流量分布
    • 监控从库延迟对业务的影响

ProxySQL 配置示例：

sql
-- 添加主库和从库
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, '192.168.1.101', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, '192.168.1.102', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, '192.168.1.103', 3306);

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*FOR UPDATE$', 10, 1);
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) VALUES (2, 1, '^SELECT', 20, 1);

-- 加载配置
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

分库分表架构 ​

架构说明：

  • 将大表拆分为多个小表（分表）
  • 将多个表分散到多个数据库实例（分库）
  • 降低单表数据量，提高查询性能
  • 支持水平扩展

分库分表策略：

  1. 垂直拆分：

    • 按业务功能拆分表
    • 例如：将用户表拆分为用户基本信息表和用户详细信息表
    • 优点：降低表复杂度，提高查询性能
    • 缺点：增加跨表join操作

  2. 水平拆分：

    • 按数据行拆分表
    • 例如：按用户ID哈希拆分用户表
    • 优点：支持大规模数据，易于扩展
    • 缺点：增加查询复杂度，需要中间件支持

拆分键选择：

  • 选择频繁用于查询条件的字段
  • 选择分布均匀的字段
  • 避免热点数据问题
  • 考虑业务增长趋势

实现方式：

  1. 应用层分库分表：

    • 在应用代码中实现分库分表逻辑
    • 例如：使用 ShardingSphere-JDBC
    • 优点：灵活，性能好
    • 缺点：耦合度高，维护复杂

  2. 中间件分库分表：

    • 使用 ProxySQL、MaxScale 或 ShardingSphere-Proxy 等中间件
    • 中间件自动路由请求
    • 优点：解耦应用和数据库，易维护
    • 缺点：增加系统复杂度和延迟

最佳实践：

  1. 拆分粒度：

    • 单表数据量建议控制在 1000万 - 5000万行
    • 单表大小建议控制在 10GB - 50GB
    • 根据查询性能调整拆分粒度

  2. 避免跨库操作：

    • 设计合理的拆分规则，减少跨库join
    • 使用全局表存储公共数据
    • 考虑使用分布式事务（如果必须）

  3. 数据迁移：

    • 分阶段迁移，先迁移非核心业务
    • 使用工具辅助迁移，如 pt-online-schema-change
    • 验证迁移后的数据一致性

  4. 监控与告警：

    • 监控各分片的性能指标
    • 监控分片数据分布情况
    • 监控跨分片查询情况

云环境架构设计 ​

云环境特点：

  • 弹性扩展能力
  • 按需付费
  • 管理服务丰富
  • 多区域部署支持

云架构选择：

  1. 托管服务 vs 自建服务：

    • 托管服务：AWS RDS for MariaDB、Azure Database for MariaDB、Google Cloud SQL for MariaDB
      • 优点：无需管理基础设施，自动备份、高可用
      • 缺点：灵活性受限，成本较高
    • 自建服务：EC2、Azure VM、Google Compute Engine
      • 优点：灵活性高，成本可控
      • 缺点：需要自行管理基础设施和数据库

  2. 云架构最佳实践：

    • 使用多可用区部署，提高可用性
    • 配置自动备份和快照
    • 使用云监控服务监控数据库性能
    • 配置合适的扩展策略
    • 考虑数据传输成本

  3. 混合云架构：

    • 核心业务留在本地，非核心业务迁移到云
    • 使用数据同步工具保持数据一致性
    • 例如：使用 MariaDB 复制将本地数据同步到云数据库

架构演进策略 ​

架构不是一成不变的，需要随着业务发展不断演进。以下是架构演进的常见路径：

  1. 阶段1：单机架构

    • 适合初创期，业务规模小
    • 简单易维护
    • 成本低

  2. 阶段2：主从复制架构

    • 适合业务增长期，读流量增加
    • 提高读性能
    • 实现数据备份

  3. 阶段3：读写分离架构

    • 适合高并发场景，读多写少
    • 进一步提高系统吞吐量
    • 减轻主库负担

  4. 阶段4：高可用集群架构

    • 适合核心业务，对可用性要求高
    • 实现自动故障切换
    • 提高系统可靠性

  5. 阶段5：分库分表架构

    • 适合大规模数据场景
    • 支持水平扩展
    • 降低单库单表压力

  6. 阶段6：分布式架构

    • 适合超大规模业务
    • 使用分布式数据库或数据库集群
    • 支持全球分布

架构演进原则：

  • 渐进式演进，避免大跃进
  • 每个阶段都进行充分测试
  • 考虑业务连续性和数据安全
  • 建立架构评估机制

架构评估与优化 ​

架构评估维度 ​

  1. 性能评估：

    • 响应时间
    • 吞吐量
    • 资源利用率
    • 并发能力

  2. 可用性评估：

    • 系统 uptime
    • 故障恢复时间（RTO）
    • 数据丢失量（RPO）
    • 故障切换成功率

  3. 可扩展性评估：

    • 垂直扩展能力
    • 水平扩展能力
    • 扩展成本
    • 扩展复杂度

  4. 成本评估：

    • 硬件成本
    • 软件成本
    • 人力成本
    • 维护成本

  5. 安全性评估：

    • 数据加密
    • 权限管理
    • 安全审计
    • 漏洞修复

架构优化方法 ​

  1. 性能优化：

    • 优化查询语句和索引
    • 调整数据库参数
    • 升级硬件或迁移到云服务
    • 引入缓存层

  2. 可用性优化：

    • 增加冗余节点
    • 优化故障切换机制
    • 定期进行灾备演练
    • 完善监控和告警

  3. 可扩展性优化：

    • 重构代码，支持水平扩展
    • 引入服务化架构
    • 设计合理的分库分表策略
    • 使用容器化和编排工具

  4. 成本优化：

    • 优化资源利用率
    • 采用按需付费模式
    • 自动化运维，减少人力成本
    • 合理规划数据存储，降低存储成本

最佳实践总结 ​

  1. 根据业务需求选择合适的架构：

    • 小型应用：单机架构
    • 中型应用：主从复制架构
    • 大型应用：高可用集群 + 读写分离
    • 超大型应用：分库分表 + 分布式架构

  2. 高可用设计是核心：

    • 避免单点故障
    • 设计合理的故障切换机制
    • 定期进行灾备演练

  3. 性能优化贯穿始终：

    • 优化查询语句和索引
    • 调整数据库参数
    • 选择合适的存储引擎
    • 引入缓存层

  4. 可扩展性设计：

    • 考虑业务增长趋势
    • 设计支持水平扩展的架构
    • 避免架构锁定

  5. 自动化运维：

    • 自动化部署和配置
    • 自动化监控和告警
    • 自动化备份和恢复
    • 自动化故障切换

  6. 持续评估和优化：

    • 定期评估架构性能
    • 监控业务增长情况
    • 及时调整架构设计
    • 跟进技术发展趋势

常见问题 (FAQ) ​

Q: 如何选择主从复制和 Galera Cluster？ ​

A: 可以从以下几个方面考虑：

  • 数据一致性：Galera Cluster 提供强一致性，主从复制提供最终一致性
  • 写入性能：高并发写入场景下，主从复制（异步）性能更好
  • 复杂性：主从复制配置简单，Galera Cluster 配置复杂
  • 扩展性：Galera Cluster 支持弹性扩展，主从复制扩展相对复杂
  • 故障恢复：Galera Cluster 自动故障恢复，主从复制需要手动或借助工具

Q: 分库分表有哪些注意事项？ ​

A: 分库分表需要注意：

  • 选择合适的拆分键，避免热点数据
  • 减少跨库操作，尤其是跨库join
  • 考虑数据迁移和扩容成本
  • 选择合适的中间件，简化分库分表管理
  • 监控各分片的性能和数据分布情况

Q: 如何设计云环境下的 MariaDB 架构？ ​

A: 云环境架构设计建议：

  • 根据业务需求选择托管服务或自建服务
  • 使用多可用区部署，提高可用性
  • 配置自动备份和快照
  • 使用云监控服务监控数据库性能
  • 考虑数据传输成本和延迟
  • 设计混合云架构，实现业务连续性

Q: 如何评估现有架构的性能？ ​

A: 架构性能评估方法：

  • 监控关键性能指标：响应时间、吞吐量、资源利用率
  • 进行基准测试，如使用 sysbench 或 tpcc-mysql
  • 分析慢查询日志，找出性能瓶颈
  • 模拟高并发场景，测试系统极限
  • 对比行业标准，评估系统性能水平

Q: 架构演进时如何保证业务连续性？ ​

A: 架构演进建议：

  • 分阶段进行，逐步迁移
  • 在测试环境中完成充分测试
  • 制定详细的回滚计划
  • 选择业务低峰期进行迁移
  • 建立完善的监控和告警机制
  • 准备应急方案，应对突发情况

Q: 如何设计读写分离架构？ ​

A: 读写分离架构设计建议：

  • 根据业务场景选择应用层或中间件实现
  • 配置合适的连接池大小
  • 处理好数据一致性问题
  • 监控从库延迟，避免影响业务
  • 设计合理的切换策略，应对从库故障

Q: Galera Cluster 适合哪些场景？ ​

A: Galera Cluster 适合以下场景：

  • 对数据一致性要求高的场景
  • 需要多主架构的场景
  • 对可用性要求高（RTO < 1分钟）
  • 读写比较均衡的场景
  • 中等规模数据量（< 10TB）

Q: 如何优化 MariaDB 架构的成本？ ​

A: 架构成本优化建议：

  • 根据业务需求选择合适的硬件配置
  • 采用按需付费模式，避免资源浪费
  • 优化资源利用率，提高服务器负载
  • 自动化运维，减少人力成本
  • 合理规划数据存储，采用分层存储策略
  • 考虑使用开源软件，降低软件成本

总结 ​

MariaDB 架构设计是一个复杂的系统工程，需要综合考虑业务需求、性能、可用性、可扩展性和成本等因素。不同的业务场景需要不同的架构方案，没有放之四海而皆准的架构。

作为 DBA，需要深入理解业务需求，掌握各种架构方案的优缺点，结合实际情况选择合适的架构。同时，架构不是一成不变的，需要随着业务发展不断演进和优化。

通过遵循本文介绍的架构设计原则和最佳实践，可以设计出高效、可靠、可扩展的 MariaDB 架构，为业务发展提供坚实的支撑。