基于 MySQL 主从复制实现配置数据与测试数据分离的架构设计

技术文章 > 架构 > 基于 MySQL 主从复制实现配置数据与测试数据分离的架构设计

#MySQL #主从复制 #低代码平台 #架构设计

MySQL 主从复制通常被用于提高读性能和数据备份，然而 MySQL 主从架构还有许多其他的应用场景。

背景与挑战

本文介绍一个相对特殊的应用场景：通过 MySQL 主从复制实现配置数据与测试数据的有效分离，在保证配置数据整洁性的同时，支持基于最新配置进行功能测试。

在内部自研的低代码开发平台中，面临以下痛点：

1. 配置维护复杂：需要在平台上进行各种配置的新增和维护
2. 测试验证必要：配置完成后需要进行相应的功能测试
3. 多环境部署：测试通过后需要将配置更新到预上线、生产等其他环境
4. 数据污染风险：如果配置和测试使用同一数据库，测试数据可能影响其他环境的部署

传统做法是在多个环境中重复进行手工配置，这种方式不仅繁琐，而且容易出错，严重影响开发效率。

解决方案：主从分离架构

核心思路

我们设计了基于 MySQL 主从复制的架构方案：

• 主库（配置环境）：专门用于配置管理，保持数据的整洁性
• 从库（测试环境）：接收主库的配置同步，同时支持测试数据写入
• 双平台部署：分别连接主从两个数据库的应用系统

特别注意： 不要使用自增主键，避免从库数据和主库冲突。

架构优势

1. 自动同步：主库配置完成后自动同步到从库，无需重复配置
2. 数据隔离：从库支持读写操作，测试数据不会污染主库
3. 配置一致性：从库始终保持与主库配置的一致性
4. 简化流程：减少了多环境间的手工配置工作

缓存一致性挑战与解决方案

问题分析

虽然主从架构简化了配置流程，但也带来了新的挑战：从库数据的变更来源增加了主库同步，如果从库应用使用了缓存机制，就会出现缓存与数据库数据不一致的问题。

方案演进

早期方案：基于 Canal 的缓存同步

由于当时无法（没有权限）修改底层（集团）自研框架，我们设计了基于 Canal 的扩展方案。该方案需要开发人员在【执行】环节实现大量针对不同表的缓存清理代码，维护成本较高。

优化方案：框架级缓存控制

后来在接触到（有权限）底层自研框架后，采用了更优雅的解决方案：

• 在框架中增加缓存控制相关属性
• 在测试从库环境中直接禁用缓存
• 彻底避免了缓存一致性问题，同时简化了代码维护

总结

通过 MySQL 主从复制架构，成功解决了低代码平台中配置数据与测试数据相互影响的问题。然而，配置如何高效更新到其他环境仍然是一个更复杂的挑战，相关的方案将在后续文章中进行介绍。