MySQL 数据库中间件介绍

发表于 阅读次数： 评论数： 本文字数： 3k 阅读时长 ≈ 3 分钟

读写分离中间件

  • TDDL
    • 出身：淘宝团队研发，大概在 2008 年左右就在淘宝内部投入使用，是一种 Client 层方案。
    • 状态：目前已很久未更新，已几乎被废弃，不建议使用。
    • 优势：支持基本 CRUD 操作和读写分离。
    • 局限：不支持 JOIN 和多表查询，依赖淘宝内部的 Diamond 配置系统，社区采用不多，适用性有限。

  • Atlas

    • 出身：奇虎 360 开源，是一种 Proxy 层方案。
    • 状态：目前已很久未更新，已几乎被废弃，不建议使用。
    • 局限：功能上较为简单，仅支持 MySQL 协议代理，主要实现读写分离、简单分表，不支持复杂的分库分表场景。

  • DBProxy

    • 出身：由美团点评公司的 DBA 团队开发维护，是在 Atlas（奇虎 360）的基础上改造 / 重构而来。
    • 状态：在美团内部广泛用于生产环境，功能较为成熟、稳定，但是目前已很久未更新，已几乎被废弃，不建议使用。
    • 局限：仅支持 MySQL（Percona 5.5 / 5.6）的读写分离；虽然支持「分表 (Table‑Sharding)」，但「分库 (DataBase‑Sharding)」功能仍是 “正在内测中 / 不完善”，对于复杂的大规模分库分表、跨库事务、动态扩容 / 迁移等场景支持有限。

  • ProxySQL

    • 出身：国外开源社区开发，专注于高性能 MySQL 代理，是一种 Proxy 层方案。
    • 优势：支持读写分离、负载均衡、查询路由、连接池、查询缓存等功能；部署灵活，性能高，可支持高并发场景；多语言客户端透明接入。
    • 局限：需要额外部署和运维中间件，网络跳转会带来一定延迟；对复杂分库分表逻辑需要额外配置，学习成本相对较高；社区活跃度高，但中文文档和案例相对少。

  • Vitess

    • 出身：Google 开发，用于构建云原生、水平可扩展的分布式数据库系统，主要是 Proxy/Cluster 层方案。
    • 优势：支持主从分离的读写分离，提供分库分表（水平切分）能力，透明处理 SQL 分布式查询，支持事务；适合大规模、高并发 MySQL 场景；云原生友好，可与 Kubernetes 等集群管理系统集成。
    • 局限：架构相对复杂，需要额外的运维和学习成本；主要面向大规模场景，对小型项目可能过于重量级；部分高级功能（如跨分片事务）需要谨慎使用。

分库分表中间件

  • Cobar

    • 出身：阿里巴巴 B2B 团队开发，诞生时间大约在 2009~2010 年，后来在 2012 年开源，是一种 Proxy 层方案。
    • 状态：目前已很久未更新，已几乎被废弃，不建议使用。
    • 局限：不支持读写分离、存储过程、跨库 JOIN、跨库分页等功能。

  • MyCat / MyCat2

    • 出身：基于 Cobar 改造，是一种 Proxy 层方案。
    • 优势：功能全面，支持事务、跨库分片、聚合计算等，不少企业已有应用案例。
    • 局限：社区更新不算频繁，相较 ShardingSphere 较年轻，稳定性和成熟度略逊，最新公开版本发布时间较早。

  • Vitess

    • 出身：Google 开发，用于构建云原生、水平可扩展的分布式数据库系统，主要是 Proxy/Cluster 层方案。
    • 优势：支持主从分离的读写分离，提供分库分表（水平切分）能力，透明处理 SQL 分布式查询，支持事务；适合大规模、高并发 MySQL 场景；云原生友好，可与 Kubernetes 等集群管理系统集成。
    • 局限：架构相对复杂，需要额外的运维和学习成本；主要面向大规模场景，对小型项目可能过于重量级；部分高级功能（如跨分片事务）需要谨慎使用。

  • ShardingSphere

    • 项目源起：
      • 由 Sharding-JDBC 演化成如今的 Apache ShardingSphere，包含多个组件：JDBC（Client 层）、Proxy（Proxy 层）、Sidecar 等。
    • Sharding-JDBC（Client 层方案）：
      • 优点：以 .jar 形式嵌入项目，运维轻松，性能接近原生 JDBC，低侵入性。
      • 局限：仅支持 Java，升级依赖分散到各个应用，需要统一发布更新。
    • ShardingSphere-Proxy（Proxy 层方案）：
      • 优点：作为独立进程部署，支持多语言客户端，接入透明，便于统一管理、运维，适合 OLAP 操作和 DBA 管理。
      • 局限：多了网络跳转，性能略逊于 JDBC，且需额外部署、维护中间件。
      • 社区活跃度：社区活跃、版本持续迭代，功能丰富，包括读写分离、分布式事务、治理、安全、多数据源等。

数据同步中间件

  • Canal

    • 出身：由阿里巴巴开源，基于 MySQL binlog 增量订阅解析，实现数据同步和异地复制。
    • 状态：社区活跃，多年在阿里内部及其他企业使用，主要针对 MySQL 数据库。
    • 优势：轻量、实时，支持单向增量同步，可作为异地灾备或数据订阅平台核心组件。
    • 局限：仅支持 MySQL；复杂事务、跨库或跨机房同步需要额外逻辑处理，功能相对基础。

  • Otter

    • 出身：由阿里巴巴开源，基于 Canal 的 binlog 解析，实现跨机房 / 异地数据库同步与容灾。
    • 状态：GitHub 开源，多年实际部署，社区资料可访问，最新版本是 v4 系列。
    • 优势：支持 MySQL 与 MySQL 双向或 MySQL 与 Oracle 单向同步，支持异构库同步、DDL 与 DML 同步、灵活的表 / 库 / 列映射，适合异地灾备与分布式数据同步场景。
    • 局限：依赖 binlog / Canal，对复杂事务或高并发强一致性要求的场景支持有限；配置部署较复杂，需要额外组件（如 ZooKeeper + 管理 Console + Node 节点）。

  • Maxwell

    • 出身：Zendesk 开源，基于 MySQL binlog 的增量数据同步工具，目标是将数据库变化流式发送到 Kafka 等系统。
    • 状态：社区活跃，主要用于 MySQL 到 Kafka、Elasticsearch 或其他数据系统的同步。
    • 优势：轻量、易部署，适合流式处理和实时 ETL 场景，能快速捕获数据库变化。
    • 局限：仅支持 MySQL，不支持复杂事务或跨库同步，功能比 Canal 更简单。

  • Debezium

    • 出身：Red Hat / Debezium 社区开源，基于 Kafka 的分布式 CDC 框架，实现多数据库的增量订阅和事件驱动。
    • 状态：活跃维护，支持 MySQL、PostgreSQL、SQL Server、MongoDB 等多种数据库。
    • 优势：多数据库支持，Kafka 集成，实时捕获变更数据，可用于事件驱动架构或数据湖更新。
    • 局限：依赖 Kafka 集群，部署配置复杂，延迟和吞吐受 Kafka 与网络影响，适合有消息系统经验的团队。

  • Flink CDC

    • 出身：Ververica / Apache Flink 社区开源，基于 Flink 流处理的 CDC 连接器，实现数据库变更实时流入 Flink 流。
    • 状态：活跃维护，支持 MySQL、PostgreSQL、SQL Server、Oracle 等数据库，适合实时数据管道。
    • 优势：支持复杂 ETL、流处理和分布式扩展，能实时同步和处理大规模数据变更。
    • 局限：依赖 Flink 集群，部署成本高，对资源和运维要求较高。

  • SymmetricDS

    • 出身：JumpMind 社区开源，面向跨数据库、跨平台的数据同步与复制中间件。
    • 状态：社区活跃，支持 MySQL、PostgreSQL、Oracle、SQL Server 等多种数据库。
    • 优势：支持双向同步、冲突检测和解决，能处理异构数据库环境，适合多库多平台场景。
    • 局限：性能受网络与数据库负载影响，部署和配置复杂，学习成本较高。

  • SynchDB

    • 出身：基于 MySQL binlog 的轻量级数据同步工具，面向简单同步场景。
    • 状态：维护活跃度一般，主要用于 MySQL 与 PostgreSQL 的单向同步。
    • 优势：轻量、易部署，适合单向数据同步和小型数据管道。
    • 局限：仅支持 MySQL，功能简单，社区采用有限，适用性受限。