学会数据库读写分离、分表分库——用Mycat，这一篇就够了！

最新推荐文章于 2024-06-06 11:24:14 发布
转载 最新推荐文章于 2024-06-06 11:24:14 发布 · 345 阅读 · 0

本文介绍Mycat数据库中间件的使用方法，探讨如何通过Mycat解决系统开发中遇到的数据库优化问题，例如SQL语句优化、代码优化、主从复制、热备切换、分表分库等。

系统开发中，数据库是非常重要的一个点。除了程序的本身的优化，如：SQL语句优化、代码优化，数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件，已经在很多产品上进行使用了。希望通过这篇文章的介绍，能学会Mycat的使用
链接 https://www.jianshu.com/p/2d1a81b2dafc 详细

Mycat分库分表生死战：垂直拆分×水平分片×行业血泪案例（实战篇一）
肖哥弹架构博客
06-22 1150
当订单表突破8000万行，你的数据库开始发出死亡呻吟：CPU飙升至98%，查询响应突破2秒，磁盘IO像垂死挣扎的心跳。这不是假设——这是某电商平台大促前夜的**真实噩梦**。他们选择的分库分表方案，在4.2秒内蒸发2400万订单，血淋淋地印证了分布式架构的残酷法则：**正确的分片让你涅槃重生，错误的设计让你坠入地狱**。
Mycat分库分表生死战：垂直拆分×水平分片×行业血泪案例（实战篇二）
肖哥弹架构博客
06-22 1151
当订单表突破8000万行，你的数据库开始发出死亡呻吟：CPU飙升至98%，查询响应突破2秒，磁盘IO像垂死挣扎的心跳。这不是假设——这是某电商平台大促前夜的**真实噩梦**。他们选择的分库分表方案，在4.2秒内蒸发2400万订单，血淋淋地印证了分布式架构的残酷法则：**正确的分片让你涅槃重生，错误的设计让你坠入地狱**。 本文将撕开理论面纱，揭示分库分表的三重生死线： 1. **垂直拆分的铁血三律**：高内聚业务域集中如何避免跨库查询风暴，低耦合设计怎样阻止级联爆炸，事务闭环为何是资金安全的最后防线
mycat分表分库
朱海燕的博客日记
08-28 772
目录 数据库分片  准备环境 配置过程 主机51和主机52的配置 （这里只写一台数据库） 配置mycat服务器 启动服务 测试MyCAT   数据库分片  如何解决 并发访问压力，单表压力过大的问题？ mycat的介绍： 什么是分库分表？  通过某种特定条件,将存放在一个数据库 ( 主机 ) 中的数据,分散存放到多个数据库 ( 主机 ) 中。 已达到分散单台设备负载的效果...
mycat原理及分表分库入门
wt077521的博客
05-27 2万+
1、什么是MyCat： MyCat是一个开源的分布式数据库系统，是一个实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。MyCat发展到...
MyCat实战只分表不分库
爬到松树上的猪
03-15 671
根据实际工作中的需要，有些业务只有部分表较大，因此不需要整体做分库分表，整理只分表不分库的一种实现方式。
【Mycat2实战】四、Mycat实现分库分表【概念篇】
笑小枫
11-21 971
首先，我们需要知道所谓"分库分表"，根本就不是一件事儿，而是三件事儿，他们要解决的问题也都不一样。这三个事儿分别是"只分库不分表"、“只分表不分库”、以及"既分库又分表"。分库：就是一个数据库分成多个数据库，部署到不同机器。分表：就是一个数据库表分成多个表。
利用mycat来进行mysql数据的分表以及分库
weixin_43889681的博客
06-14 785
关于为什么要分表以及分库，可以在这个链接里面得出答案： https://www.cnblogs.com/phpper/p/6937896.html 这边的话我使用的中间件 mycat来进行分表和分库的: 首先在github 上面把压缩包下下来: https://github.com/MyCATApache/Mycat-download， 根据自己想要的 然后：利用cmd命令将mycat启动起来,记...
MySQL篇——详细分库分表原理，深入解读分库分表时机、策略以及生产解决方案！
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
06-06 1775
MySQL分库分表是为了解决大规模数据的存储和查询问题。当一个应用的数据量逐渐增大，单个数据库可能无法满足存储和查询的需求，这时就需要进行分库分表。分库指的是将数据按照一定的规则拆分到多个数据库中，每个数据库中存放一部分数据。通过分库可以提升存储的能力，每个数据库可以存储更多的数据量。分表指的是将一张大表按照一定的规则拆分成多个小表，每个小表只存放一部分数据。通过分表可以提升查询的性能，每个小表查询的数据量较少，查询速度更快。
MySQL数据库之分库分表方案
weixin_71682097的博客
06-10 2921
MySQL数据库之分库分表方案
购物商城订单分库分表应该如何设计
老王随聊
04-08 732
ShardingSphere是一款起源于当当网内部的应用框架。2015年在当当网内部诞生，最初就叫ShardingJDBC。2016年的时候，由其中一个主要的开发人员张亮，带入到京东数科，组件团队继续开发。在国内历经了当当网、电信翼支付、京东数科等多家大型互联网企业的考验，在2017年开始开源。并逐渐由原本只关注于关系型数据库增强工具的ShardingJDBC升级成为一整套以数据分片为基础的数据生态圈，更名为ShardingSphere。到2020年4月，已经成为了Apache软件基金会的顶级项目。
Mycat的简单使用（三）【分库分表】
2401_84093203的博客
04-07 291
外链图片转存中…(img-84Z6vq9O-1712466759382)][外链图片转存中…(img-AVcHIwei-1712466759383)]
Mycat分库分表详细操作
热门推荐
斌小哥的博客
08-09 5万+
  1.首先在Mycat官网下载安装包,这里就以最新的1.6版本为例,下载地址为: http://dl.mycat.io/1.6-RELEASE/ 2.解压完成后，主要编辑的配置文件在conf目录下,分别为schema.xml、rule.xml、server.xml、sequence_db_conf.properties四个文件。 schema.xml主要配置物理数据库的信息，逻辑数据库名称...
Mycat分库分表
jaysonhu的博客
10-21 2551
mycat分片规则 规则种类，在rule.xml文件中<table name="t_config" primaryKey="id" dataNode="dn1,dn2" rule="规则名" />sharding-by-intfile 分片枚举 rule1 固定分片hash算法 auto-sharding-long 范围约定 mod-long 取模 sharding-by-date 按日期（
分库分表简单分析--中间件mycat使用
u010688011的博客
05-17 1218
(1)  部署环境      mycat是java开发，linux上安装jdk。      Java Oracle官方下载地址为：（选择linux版本）http://www.oracle.com/technetwork/java/javase/archive-139210.html(2) 安装jdk环境 解压 jdk-8u162-linux-x64.tar.gz文件，并配置java的环境变量ux-...
Mycat 读写分离+分库分表
benluobobo的专栏
04-08 3万+
上次进过GTID复制的学习记录，已经搭建好了主从复制的服务器，现在利用现有的主从复制环境，加上正在研究的Mycat，实现了主流分布式数据库的测试 Mycat就不用多介绍了，可以实现很多分布式数据库的功能，极大的减轻数据库服务器的压力，包括读写分离以及分库分表，本测试对这两种功能都进行了测试，进行相应记录 本文以Mycat官方给出的例子来进行解释总结
物化视图 读写分离
shengyao15的专栏
02-06 334
物化视图 区别于一般的视图,将数据保存在硬盘中, 查询时直接从物化视图中取. 而视图只是逻辑上的将多张表关联起来, 实际查询时还是从多张表中取数据. 实际上,物化视图没多大意义,花费很多资源去同步这张物化视图表. Memcache DB内部的缓存 都使得查询快了很多. 复杂的查询用solr也能解决 读写分离 从双机热备功能发展而来的, 一台主server接受用户的CURD,...
分库分表总结，Mycat从入门到放弃
bai020的博客
05-22 1万+
之前调研分库分表框架，最后选择了sharding-jdbc，下面是我总结的各个框架：Atlas：不能实现分布式分表，所有的子表必须在同一台DB的同一个database里且所有的子表必须事先建好，Atlas没有自动建表的功能。Cobar：必须将拆分后的表分别放入不同的库来实现分布式。TDDL：阿里，功能强大，过于复杂，部分开源。需要评估使用情况，防止过剩。阿里云能买到完整的。Mycat ：国内开源，...
含多类型充电桩的电动汽车充电站优化配置方法（Matlab代码实现）
最新发布
01-04
含多类型充电桩的电动汽车充电站优化配置方法（Matlab代码实现）内容概要：本文围绕含多类型充电桩的电动汽车充电站优化配置方法展开，基于Matlab代码实现，旨在解决充电站中不同类型充电桩的合理配置问题，以提升充电效率、降低运营成本并满足用户需求。文中结合实际应用场景，构建数学优化模型，可能涉及目标函数设计（如最小化投资成本、最大化服务能力）、约束条件（如电力容量限制、空间布局限制）以及多类型充电桩（如快充、慢充、超
主库写从库读是什么意思
08-17
<think>嗯，用户现在想深入理解"主库写从库读"的概念及其在数据库架构中的实现方式。从对话历史看，用户已经具备SQL基础，但需要应对高并发场景，之前我给出了分层的技术方案，现在用户聚焦在主从架构这个基础组件上。 用户可能正在设计一个需要承载高流量的系统，或者遇到了数据库性能瓶颈。ta特意引用了三篇关于读写分离和主从复制的资料，说明需要权威的技术解释。有趣的是，用户特别强调"不是真正需求"，暗示需要抛开引用材料直接回答本质问题——这很聪明，因为很多技术文档会堆砌术语。 主从分离的核心其实可以用"分工协作"来比喻：主库像仓库管理员只管收货（写操作），从库像售货员只管发货（读操作）。但要解释清楚五个技术要点： 第一是数据同步机制，binlog日志传输就像仓库管理员实时抄写收货单给售货员； 第二是读写路由，需要说明应用层如何智能分配请求（比如Spring AOP切面）； 第三要强调主从延迟这个致命问题，电商下单后立即查不到订单就是典型故障； 第四是容灾价值，比如主库宕机时从库如何顶替； 最后必须提醒不适用场景，比如银行转账这种强一致性操作。 用户可能没意识到的是主从架构对开发习惯的影响。比如我们禁止开发使用last_insert_id()这类依赖即时性的函数，这个实战经验比理论更重要。另外可以准备一个故障案例：某公司因从库延迟导致用户看到"幽灵订单"，最后通过半同步复制解决的。 回复时会把MySQL线程复制模型画成管道图，这样比文字描述更直观。还要强调几个数字：主从延迟通常控制在500ms内，但跨机房可能到2秒——这些具体指标对架构决策很关键。最后补充个冷知识：MySQL 8.0的并行复制能力可以把延迟压缩到100ms内。</think>### 主库写从库读详解 #### 一、核心概念 **主库写从库读**是一种数据库架构设计策略： 1. **主库（Master）** - 唯一处理写操作（`INSERT/UPDATE/DELETE`） - 数据变更通过**二进制日志（Binlog）** 同步到从库 - 承担数据一致性的最终责任 2. **从库（Slave）** - 只处理读操作（`SELECT`） - 通过**主从复制**实时（或有延迟）同步主库数据 - 可水平扩展多个实例分担读压力 > 例如订单系统：用户下单（写主库），查询订单（读从库）[^1]。 #### 二、实现原理 ```mermaid sequenceDiagram App->>Master: 执行写操作 Master->>Binlog: 记录数据变更 Binlog->>Slave: 传输日志(异步/半同步) Slave->>Relay Log: 接收日志 Slave->>Slave SQL Thread: 重放SQL变更 App->>Slave: 执行读操作 ``` 1. **主从复制流程** - **Binlog生成**：主库将数据变更写入二进制日志 - **日志传输**：I/O线程将Binlog发送到从库的中继日志（Relay Log） - **数据重放**：从库的SQL线程解析Relay Log并执行SQL[^1] 2. **同步模式对比** | **模式** | 数据一致性 | 性能影响 | 故障风险 | |----------------|-----------|----------|----------| | 异步复制 | 弱 | 低 | 可能丢数据 | | 半同步复制 | 强 | 中 | 主库阻塞风险 | | 全同步复制 | 最强 | 高 | 严重性能下降 | #### 三、架构实现步骤 1. **数据库部署** ```bash # 主库配置 (my.cnf) server-id=1 log-bin=mysql-bin binlog-format=ROW # 从库配置 server-id=2 relay-log=mysql-relay read-only=1 # 禁止从库写操作 ``` 2. **建立主从链路** ```sql -- 主库创建复制账号 CREATE USER 'repl'@'%' IDENTIFIED BY 'Pass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; -- 从库启动复制 CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl', MASTER_PASSWORD='Pass123!', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; START SLAVE; ``` 3. **应用层路由** - **代码注解**（Spring Boot示例）： ```java @Service public class OrderService { @Transactional @WriteDataSource // 写操作路由到主库 public void createOrder(Order order) { orderMapper.insert(order); } @ReadDataSource // 读操作路由到从库 public Order getOrder(Long id) { return orderMapper.selectById(id); } } ``` - **中间件方案**： 通过ShardingSphere/MyCAT自动路由读写请求 #### 四、核心价值 1. **性能提升** - 读操作扩展：添加从库即可提升读吞吐量 - 写操作专注：主库无需处理查询压力 2. **高可用保障** - 主库故障时，从库可切换为新主库（需配合MHA等工具） - 从库故障不影响主库写服务 3. **容灾能力** - 跨机房部署：从库放在不同可用区 - 数据备份：从库可承担备份任务而不影响主库 > 📌 **注意**：主从延迟可能导致"刚写入的数据查不到"，需通过以下方案缓解： > - 关键业务强制读主库（如支付结果查询） > - 半同步复制（`rpl_semi_sync_master_wait_for_slave_count=1`） > - 监控延迟：`SHOW SLAVE STATUS`中的`Seconds_Behind_Master`[^2] #### 五、典型应用场景 1. 电商系统：商品浏览（读从库） vs 下单（写主库） 2. 社交平台：动态读取（读从库） vs 发帖（写主库） 3. 数据分析：从库专供报表查询，避免影响交易主库 > 💡 **最佳实践**： > - 从库数量建议不超过5个（避免复制链过长） > - 定期校验主从数据一致性（pt-table-checksum工具） > - 读写分离+分库分表组合应对超大规模并发[^3] --- ### 相关问题 1. 主从复制延迟超过10秒时有哪些应急处理方案？ 2. 如何设计一套自动化的主从切换机制？ 3. 在微服务架构中如何动态管理读写数据源？ 4. MySQL主从复制与Redis主从复制有何本质区别？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值