MySQL读写分离—— ProxySQL & MyCAT & ShardingSphere
实现MySQL读写分离确实有多种成熟的中间件方案可供选择。
最常用的三种中间件及其核心特性,如下:
特性 |
ProxySQL |
MyCAT |
ShardingSphere |
---|---|---|---|
类型 |
独立部署的代理(Proxy) |
独立部署的数据库中间件 |
嵌入应用的驱动(JDBC)或独立代理 |
核心优势 |
高性能、规则灵活、功能专注 |
功能全面、支持分库分表 |
对应用透明、无代理、性能损耗低 |
读写分离 |
支持,基于灵活规则 |
支持 |
支持 |
负载均衡 |
支持 |
支持 |
支持 |
分库分表 |
不支持 |
支持 |
支持 |
连接池 |
支持 |
支持 |
不适用(直连) |
适用场景 |
高并发、对延迟敏感、需复杂路由 |
大型分布式系统,需读写分离+分库分表 |
Java技术栈,希望架构简单、高性能 |
⚙️ 技术基石:主从复制
无论采用哪种路由方式,读写分离都强烈依赖于MySQL的主从复制(Master-Slave Replication) 机制来保证从库数据与主库最终一致。其基本工作流程如下:
-
主库写二进制日志:主库将数据变更操作记录到二进制日志(Binary Log)中
-
从库拉取日志:从库的I/O线程连接到主库,读取主库的二进制日志事件并写入到本地的中继日志(Relay Log)中
-
从库重放日志:从库的SQL线程读取中继日志,并重放其中的SQL事件,从而使从库数据与主库保持一致
需要注意的是,主从复制通常是异步的,这意味着主库上的写入不会立即同步到从库,因此存在短暂的复制延迟,这导致了读写分离架构是最终一致性的
MySQL 的分库分表是一种应对海量数据和高并发访问的数据库架构设计技术,其核心目标是提升数据库的扩展性、性能和高可用性。
下面通过一个表格来了解其核心拆分策略
拆分维度
拆分类型
核心思路与目的
常见拆分依据
分库
垂直分库
按业务模块划分(如订单库、用户库),实现专库专用,降低单库压力并业务解耦。
业务功能模块
水平分库
将同一业务数据按规则分布到多个数据库,解决单库存储与并发瓶颈。
用户ID取模、时间范围、地理位置
分表
垂直分表
将一张宽表的字段拆成多张表(如热点字段与冷字段分离),减少单表宽度,提升IO效率。
字段访问频次
水平分表
将同一张表的数据按规则拆分成多个表结构相同的表,解决单表数据量过大的问题。
用户ID哈希、时间范围
一. ProxySQL
ProxySQL是一个高性能、专注于MySQL的代理层中间件。它作为一个独立的服务部署在应用程序和数据库集群之间
- 工作原理:应用程序直接连接ProxySQL。ProxySQL会拦截所有SQL请求,并根据管理员预定义的规则(例如,通过正则表达式匹配SQL语句类型),将写操作(
INSERT
,UPDATE
,DELETE
)路由到主库(Master),将读操作(SELECT
)分发到多个从库(Slave)中的一个,从而实现负载均衡
核心特性:
- 读写分离和负载均衡:ProxySQL 能够自动将写操作路由到主库(Master),将读操作分发到一个或多个从库(Slave),并支持基于权重、连接数等多种负载均衡算法,有效分散数据库压力
- 灵活路由:这是 ProxySQL 最核心的功能之一。你可以基于 SQL 语句内容(通过正则表达式匹配)、用户名、客户端地址甚至 访问端口 来定制复杂的路由规则
- 连接池和多路复用:它有效管理数据库连接,减少频繁建立和断开 TCP 连接的开销,并通过连接复用技术显著提升性能,尤其在高并发场景下效果明显
- 动态配置:ProxySQL 采用独特的三层配置架构(Runtime, Memory, Disk),允许几乎所有的配置都在线修改,并立即生效或轻松回滚,无需重启服务,这为生产环境维护提供了极大便利
- 监控和查缓存:它内置了丰富的监控指标,可以追踪 SQL 执行性能、连接状态和主机健康度。同时,查询缓存功能可以缓存特定查询的结果,直接返回以减轻数据库负担
⚙️ 核心配置流程
配置 ProxySQL 通常遵循以下步骤,这能让你对其工作方式有更具体的认识:
- 定义后端数据库服务器:在
mysql_servers
表中添加你的 MySQL 主库和从库信息,并使用hostgroup_id
对它们进行逻辑分组(例如,10 为写组,20 为读组)-
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'master-server', 3306), (20, 'slave-server-1', 3306), (20, 'slave-server-2', 3306);
-
- 配置监控用户:设置一个用于 ProxySQL 监控后端数据库健康状态的用户
-
UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username'; UPDATE global_variables SET variable_value='monitor_password' WHERE variable_name='mysql-monitor_password';
-
- 注册应用访问用户:将应用程序连接数据库时使用的用户名和密码配置到
mysql_users
表中,并指定其默认访问的主机组-
INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('app_user', 'password', 10);
-
- 设置读写分离规则:在
mysql_query_rules
表中创建规则,根据 SQL 语句的类型进行路由-
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*FOR UPDATE$', 10, 1), -- SELECT FOR UPDATE 也发往写组 (2, 1, '^SELECT', 20, 1), -- 普通 SELECT 发往读组 (3, 1, '.*', 10, 1); -- 其他所有语句发往写组
-
- 激活配置:使用
LOAD ... TO RUNTIME
命令使内存中的配置立即生效,然后使用SAVE ... TO DISK
命令将配置持久化-
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;
-
二. MyCAT
MyCAT是一个功能强大的分布式数据库中间件,它不仅支持读写分离,更核心的功能是处理大数据量的分库分表。支持多种数据库,包含MySQL、Oracle、SQL Server等。
下面这个表格汇总了 MyCAT 的核心概念,帮助你快速理解其架构逻辑。
核心概念 |
说明 |
---|---|
逻辑库 (Schema) |
面向应用程序的虚拟数据库。应用程序连接的是 MyCAT 提供的逻辑库,无需感知后端的物理数据库集群 |
逻辑表 (Table) |
应用程序操作的表。在逻辑上存在,其数据可能物理存储在一个或多个实际的数据库表中 |
分片节点 (DataNode) |
标识数据分片的具体位置,格式通常为 |
节点主机 (DataHost) |
定义物理数据库服务器的信息,包括主从关系、读写分离和故障切换策略等 |
分片规则 (Rule) |
决定数据如何被分布到不同分片的规则,如取模、范围、哈希等 |
🔧 核心功能
MyCAT 的强大之处在于它提供了一整套数据库集群管理解决方案。
- 数据分片:这是 MyCAT 最核心的功能。它支持水平分片(按行拆分)和垂直分片(按表或库拆分)。通过配置分片规则,可以将海量数据分布到不同的数据库节点上,有效解决单机存储和性能瓶颈。例如,可以按用户ID的哈希值将用户表数据分散到多个数据库中,或者按月份将订单表拆分到不同的表
- 读写分离:MyCAT 可以配合 MySQL 的主从复制,实现读写分离。写操作(如 INSERT, UPDATE, DELETE)被路由到主库(Master),而读操作(如 SELECT)则被分发到一个或多个从库(Slave)上,从而显著提升数据库的读并发能力
- 高可用性:通过内置的心跳检测机制,MyCAT 能够监控后端数据库节点的状态。当主库发生故障时,它可以自动进行故障切换,将写操作指向新的主库,保障服务的可用性
- 分片式查询:对于跨多个分片的查询,MyCAT 能够将查询分解到不同的节点并行执行,并对返回的结果进行汇聚、排序等处理,最后将最终结果返回给客户端,这对应用层是透明的
⚙️ 工作原理与配置
MyCAT 的工作原理可以概括为 “拦截、分析、路由、返回”
-
拦截:MyCAT 作为代理,拦截应用程序发送的所有 SQL 请求。
-
分析:对 SQL 语句进行解析,包括分片分析、路由分析、读写分离分析等。
-
路由:根据分析结果和配置规则,将 SQL 语句路由到后端一个或多个正确的数据库节点上执行。
-
返回:收集各个节点返回的数据,进行必要的聚合处理,最后将结果返回给应用程序
配置 MyCAT 主要涉及三个核心文件:
-
server.xml:用于定义连接 MyCAT 的用户及其权限、管理端口等系统级参数。
-
schema.xml:这是核心配置文件,用于定义逻辑库、逻辑表、数据节点(DataNode)以及数据源(DataHost),包括读写分离和故障切换策略。
-
rule.xml:在此文件中定义分片规则,例如通过配置
<tableRule>
和<function>
来指定如何根据某个字段(如用户ID)进行数据分片
三. ShardingSphere
Apache ShardingSphere 是一个功能强大的开源分布式数据库中间件生态系统,它旨在为传统关系型数据库提供分布式能力的增强。下面这个表格可以帮助你快速抓住它的核心组成和特点。
组件 |
类型 |
核心特点 |
适用场景 |
---|---|---|---|
ShardingSphere-JDBC |
Jar包形式,嵌入应用 |
轻量级,对应用透明,性能高,无需独立部署 |
Java应用,追求极致性能,架构简单 |
ShardingSphere-Proxy |
独立数据库代理服务 |
对应用完全透明,支持多语言,对DBA友好 |
异构语言环境,数据库运维管理,OLAP场景 |
ShardingSphere-Sidecar |
Sidecar代理(规划中) |
云原生设计,与Kubernetes集成 |
云原生环境,Service Mesh架构 |
🔧 核心功能解析
ShardingSphere 提供了一系列强大的功能来解决分布式环境下的数据库难题
- 数据分片:这是 ShardingSphere 最核心的功能。它支持水平分库和水平分表
- 读写分离:通过配置主从数据库架构,ShardingSphere 可以自动将写操作路由到主库,将读操作负载均衡到多个从库,从而显著提升系统的读并发能力和整体性能
- 分布式事务:ShardingSphere 提供了强大的分布式事务支持,包括基于 XA 协议的强一致性事务和基于 SAGA 及 Seata 的柔性事务,确保数据在跨多个分片时的一致性
- 数据加密与脱敏:该功能可以透明地对存入数据库的敏感数据(如手机号、身份证号)进行加密或脱敏处理,在数据查询时再自动解密,保障数据安全,对应用程序无侵入
- 弹性伸缩与数据治理:ShardingSphere 还提供了诸如弹性扩容(规划中)、配置动态化、数据迁移(通过 ShardingSphere-Scaling)、影子库压测等数据库治理能力,帮助更好地管理分布式数据库集群
⚙️ 工作原理简介
ShardingSphere 的核心工作原理可以概括为 “拦截、解析、改写、路由、归并”。
- SQL 解析:当应用程序发送一条 SQL 到 ShardingSphere 时,它首先会使用内置的 SQL 解析引擎对 SQL 进行词法和语法分析,理解其含义
- 查询改写:根据解析结果和配置的分片规则,ShardingSphere 会将逻辑SQL改写成可以在真实物理数据库上执行的语句。例如,
SELECT * FROM t_order
可能会被改写成SELECT * FROM t_order_0
和SELECT * FROM t_order_1
等 - SQL路由:根据分片键的条件,路由引擎会决定这条SQL应该到哪个或哪些物理分片上去执行
- 结果归并:将从各个数据节点获取的多结果集(比如分页查询结果)进行归并,最终整合成一个完整的结果集返回给应用程序
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/937389.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!