当前位置： 首页 > news >正文

【6.1.1 漫画分库分表】

news 2025/7/13 12:14:18

漫画分库分表

“数据量大了不可怕，可怕的是不知道如何优雅地拆分。”

🎭 人物介绍

  • 架构师老王：资深数据库架构专家，精通各种分库分表方案
  • Java小明：对分库分表充满疑问的开发者
  • ShardingSphere师傅：Apache ShardingSphere的化身，国产分库分表框架代表
  • Mycat大师：Mycat框架的化身，数据库中间件专家
  • Vitess长老：Google Vitess的化身，云原生数据库集群方案
  • 数据库老爷：传统数据库的代表，见证了数据增长的痛苦

本节导言

Java小明：（困惑地）老王，我们的用户表已经有几千万条数据了，查询越来越慢，该怎么办？

架构师老王：（点头）这是典型的数据量增长问题！单表数据量过大时，我们需要考虑分库分表了。

数据库老爷：（叹气）想当年我一个人就能处理所有数据，现在…

ShardingSphere师傅：（自信地）别担心！我们有完整的分库分表解决方案，从水平拆分到垂直拆分，一应俱全！

Mycat大师：（稳重地）我擅长数据库代理，让应用无感知地使用分库分表。

Vitess长老：（淡定地）在Google，我们处理的是全球级别的数据量，云原生是未来趋势。

1. 分库分表基础概念

1.1 什么是分库分表

架构师老王：分库分表是应对大数据量和高并发的数据库优化策略，通过将数据分散到多个数据库和表中来提升性能。

分库分表后
单库单表
数据库1
数据库2
数据库3
数据库4
user_0
1250万
user_1
1250万
user_2
1250万
user_3
1250万
user_4
1250万
user_5
1250万
user_6
1250万
user_7
1250万
用户表
5000万条记录

1.2 分库分表的类型

垂直拆分 vs 水平拆分
拆分方式垂直拆分水平拆分
分库按业务模块拆分按数据特征拆分
分表按字段拆分按数据量拆分
适用场景微服务架构单表数据量过大
复杂度相对简单相对复杂

2. 主流分库分表框架对比

2.1 Apache ShardingSphere

ShardingSphere师傅：我是Apache顶级项目，提供完整的分库分表生态！

核心特性
/*** ShardingSphere配置示例*/
@Configuration
public class ShardingSphereConfig {// 数据源配置@Beanpublic DataSource dataSource() {Map<String, DataSource> dataSourceMap = new HashMap<>();dataSourceMap.put("ds0", createDataSource("jdbc:mysql://localhost:3306/db0"));dataSourceMap.put("ds1", createDataSource("jdbc:mysql://localhost:3306/db1"));// 分片规则ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();shardingRuleConfig.getTableRuleConfigs().add(getUserTableRuleConfiguration());shardingRuleConfig.getBindingTableGroups().add("user");shardingRuleConfig.setDefaultDatabaseShardingStrategyConfig(new InlineShardingStrategyConfiguration("user_id", "ds${user_id % 2}"));return ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, Collections.singleton(shardingRuleConfig), new Properties());}private TableRuleConfiguration getUserTableRuleConfiguration() {TableRuleConfiguration config = new TableRuleConfiguration("user", "ds${0..1}.user_${0..3}");config.setTableShardingStrategyConfig(new InlineShardingStrategyConfiguration("user_id", "user_${user_id % 4}"));return config;}
}
优势与劣势
优势 ✅劣势 ❌
生态完善，文档丰富学习曲线较陡峭
支持多种数据库配置相对复杂
读写分离、分布式事务性能开销相对较大
社区活跃，国产化依赖较多

2.2 Mycat

Mycat大师：我是数据库中间件的先驱，专注于透明化的数据库代理！

核心架构
<!-- Mycat server.xml配置 -->
<mycat:server xmlns:mycat="http://io.mycat/"><system><property name="serverPort">8066</property><property name="managerPort">9066</property><property name="charset">utf8</property><property name="processors">4</property><property name="processorExecutor">8</property></system><user name="mycat"><property name="password">mycat</property><property name="schemas">testdb</property></user>
</mycat:server>

<!-- schema.xml配置 -->
<schema name="testdb" checkSQLschema="false" sqlMaxLimit="100"><table name="user" primaryKey="id" dataNode="dn1,dn2,dn3,dn4" rule="mod-long" />
</schema><dataNode name="dn1" dataHost="localhost1" database="db1" />
<dataNode name="dn2" dataHost="localhost1" database="db2" />
<dataNode name="dn3" dataHost="localhost2" database="db3" />
<dataNode name="dn4" dataHost="localhost2" database="db4" />
优势与劣势
优势 ✅劣势 ❌
部署简单，上手快功能相对单一
性能优秀社区活跃度下降
对应用透明复杂查询支持有限
成熟稳定缺乏现代化特性

2.3 Vitess (Google)

Vitess长老：我来自Google，专为云原生和大规模数据处理而生！

核心特性
# Vitess Kubernetes配置
apiVersion: planetscale.com/v2
kind: VitessCluster
metadata:name: example
spec:images:vtgate: vitess/lite:latestvttablet: vitess/lite:latestcells:- name: zone1gateway:replicas: 2keyspaces:- name: commerceturndownPolicy: Immediatepartitionings:- equal:parts: 4shardTemplate:databaseInitScriptSecret:name: example-cluster-configkey: init_db.sql
优势与劣势
优势 ✅劣势 ❌
云原生架构学习成本高
超大规模数据支持生态相对较小
自动化运维主要面向MySQL
Google技术背景国内使用较少

3. 国内外优秀框架全览

3.1 国内主流框架

3.1.1 ShardingSphere (Apache)
  • 开发公司：当当网 → Apache基金会
  • GitHub Stars：19.6k+
  • 特点：功能最全面的分库分表解决方案
3.1.2 Mycat
  • 开发公司：Mycat开源社区
  • GitHub Stars：9.5k+
  • 特点：数据库中间件，性能优秀
3.1.3 TDDL (Taobao Distributed Data Layer)
  • 开发公司：阿里巴巴
  • GitHub Stars：5.5k+
  • 特点：淘宝自研，久经考验
3.1.4 Cobar
  • 开发公司：阿里巴巴
  • GitHub Stars：2.2k+
  • 特点：早期分库分表方案，Mycat前身
3.1.5 Atlas
  • 开发公司：奇虎360
  • GitHub Stars：4.1k+
  • 特点：基于MySQL-Proxy，读写分离

3.2 国外优秀框架

3.2.1 Vitess (Google)
  • 开发公司：Google
  • GitHub Stars：17.8k+
  • 特点：YouTube使用，云原生架构
3.2.2 Citus (Microsoft)
  • 开发公司：Microsoft
  • GitHub Stars：9.8k+
  • 特点：PostgreSQL分布式扩展
3.2.3 ProxySQL
  • 开发公司：ProxySQL LLC
  • GitHub Stars：5.9k+
  • 特点：高性能MySQL代理
3.2.4 MaxScale (MariaDB)
  • 开发公司：MariaDB Corporation
  • GitHub Stars：1.3k+
  • 特点：数据库代理和负载均衡
3.2.5 Gizzard (Twitter)
  • 开发公司：Twitter
  • GitHub Stars：2.3k+
  • 特点：分片框架，已停止维护

3.3 详细功能对比矩阵

国外框架对比
国内框架对比
Vitess
🇺🇸 Google
Citus
🇺🇸 Microsoft
ProxySQL
🇮🇹 ProxySQL LLC
MaxScale
🇫🇮 MariaDB
✅ 分库分表
✅ 读写分离
✅ 在线DDL
✅ 自动故障转移
✅ 备份恢复
✅ 云原生
✅ 分库分表
✅ 读写分离
✅ 分布式查询
✅ 实时分析
✅ 列式存储
✅ PostgreSQL
❌ 分库分表
✅ 读写分离
✅ 连接池
✅ 查询路由
✅ 故障转移
✅ 高性能
❌ 分库分表
✅ 读写分离
✅ 负载均衡
✅ 故障转移
✅ 监控
✅ MariaDB
ShardingSphere
🇨🇳 当当网→Apache
Mycat
🇨🇳 开源社区
TDDL
🇨🇳 阿里巴巴
Cobar
🇨🇳 阿里巴巴
Atlas
🇨🇳 奇虎360
✅ 分库分表
✅ 读写分离
✅ 分布式事务
✅ 数据脱敏
✅ 影子表
✅ 弹性伸缩
✅ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 负载均衡
✅ 分库分表
✅ 读写分离
✅ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 动态数据源
✅ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 连接池
❌ 分库分表
✅ 读写分离
❌ 分布式事务
❌ 数据脱敏
❌ 影子表
✅ 负载均衡

3.4 综合性能对比

框架QPS延迟资源消耗适用规模主要数据库
ShardingSphere中等低中等中大型MySQL/PostgreSQL/Oracle
Mycat高极低低中型MySQL
Vitess极高低高超大型MySQL
TDDL中等低中等中大型MySQL
Cobar高极低低中型MySQL
Citus高低中等大型PostgreSQL
ProxySQL极高极低低中大型MySQL
Atlas高极低低中型MySQL

3.5 生态系统与维护状态

框架社区活跃度文档质量企业支持学习成本维护状态
ShardingSphere🟢 极高🟢 优秀🟢 强🟡 中等🟢 活跃
Mycat🟡 中等🟡 一般🟡 中等🟢 低🟡 缓慢
Vitess🟢 高🟢 优秀🟢 强🔴 高🟢 活跃
TDDL🟡 中等🟡 一般🟢 强🟡 中等🟡 内部
Cobar🔴 低🔴 较差🔴 弱🟢 低🔴 停止
Citus🟢 高🟢 优秀🟢 强🟡 中等🟢 活跃
ProxySQL🟢 高🟢 优秀🟢 强🟡 中等🟢 活跃
Atlas🟡 中等🟡 一般🟡 中等🟢 低🟡 缓慢

3.6 企业应用案例

国内知名企业使用情况
框架知名用户应用场景
ShardingSphere京东、滴滴、哔哩哔哩、转转电商、出行、视频、二手交易
Mycat阿里云、腾讯云、华为云云数据库服务
TDDL淘宝、天猫、支付宝电商、支付
VitessYouTube、Slack、GitHub视频、协作、代码托管
CitusMicrosoft、Heap、MixRank云服务、分析、营销
行业应用分布
35%25%15%12%8%5%分库分表框架行业应用分布电商零售金融支付社交媒体企业服务游戏娱乐其他

4. 技术选型指南

4.1 选型决策树

千万级
亿级
十亿级+
较强
一般
选择分库分表方案
数据量级别?
ShardingSphere
功能全面，易上手
团队技术水平?
Vitess
超大规模专用
ShardingSphere
或 自研方案
Mycat
简单稳定
适合：
• 中小型互联网公司
• 快速迭代项目
• 需要完整生态
适合：
• 传统企业
• 稳定性优先
• 简单分片需求
适合：
• 大型互联网公司
• 复杂业务场景
• 有技术团队
适合：
• 超大规模应用
• 云原生架构
• 全球化部署

4.2 具体场景推荐

🏢 企业级应用
/*** 企业级分库分表选型*/
public class EnterpriseScenario {// 传统企业 - 稳定优先public void traditionalEnterprise() {/** 推荐：Mycat* * 理由：* • 部署运维简单* • 性能稳定可靠* • 对现有系统改动小* • 技术门槛低*/}// 互联网公司 - 功能优先public void internetCompany() {/** 推荐：ShardingSphere* * 理由：* • 功能丰富完善* • 生态系统成熟* • 社区支持好* • 持续更新迭代*/}// 大型互联网 - 性能优先public void largeScaleInternet() {/** 推荐：Vitess 或 自研* * 理由：* • 超大规模数据支持* • 云原生架构* • 自动化运维* • 可定制性强*/}
}

5. 实战案例对比

5.1 电商系统分库分表

/*** 电商系统分库分表实战*/
public class ECommerceSharding {// 用户表分片策略public void userTableSharding() {/** 分片键：user_id* 分片算法：hash取模* 分库：4个库* 分表：每库4张表* * 路由规则：* 库：user_id % 4* 表：user_id % 16 / 4*/}// 订单表分片策略public void orderTableSharding() {/** 分片键：user_id (保证用户订单在同一库)* 分片算法：hash取模* 时间维度：按月分表* * 路由规则：* 库：user_id % 4* 表：order_202401, order_202402...*/}
}

5.2 金融系统分库分表

/*** 金融系统分库分表实战*/
public class FinancialSharding {// 账户表分片策略public void accountTableSharding() {/** 分片键：account_id* 分片算法：range分片* 分库：按账户号段* * 路由规则：* 1-100万：db1* 100-200万：db2* 200-300万：db3*/}// 交易流水表分片策略public void transactionTableSharding() {/** 分片键：account_id + 时间* 分片算法：复合分片* * 路由规则：* 先按account_id确定库* 再按时间确定表*/}
}

6. 数据同步与读写分离方案

6.1 数据同步框架对比

6.1.1 Canal (阿里巴巴)
/*** Canal数据同步示例*/
public class CanalDataSync {public void startCanalClient() {// 创建链接CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress("127.0.0.1", 11111), "example", "", "");try {connector.connect();connector.subscribe(".*\\..*");connector.rollback();while (true) {Message message = connector.getWithoutAck(1000);long batchId = message.getId();if (batchId != -1 && !message.getEntries().isEmpty()) {processEntries(message.getEntries());}connector.ack(batchId);}} finally {connector.disconnect();}}
}
6.1.2 Maxwell (Zendesk)
{"database": "test","table": "users","type": "insert","ts": 1449786310,"xid": 23396,"data": {"id": 1,"name": "张三","email": "zhangsan@example.com"}
}
6.1.3 Debezium (Red Hat)
# Debezium MySQL连接器配置
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:name: debezium-connect
spec:replicas: 1bootstrapServers: kafka-cluster:9092config:group.id: debezium-clusteroffset.storage.topic: debezium-cluster-offsetsconfig.storage.topic: debezium-cluster-configsstatus.storage.topic: debezium-cluster-status
数据同步框架对比
框架开发公司特点适用场景优势劣势
Canal阿里巴巴基于MySQL binlog实时同步性能高、稳定仅支持MySQL
MaxwellZendeskJSON格式输出数据分析简单易用功能相对简单
DebeziumRed Hat基于Kafka Connect微服务架构生态丰富复杂度较高
DataX阿里巴巴离线批量同步数据迁移支持多数据源非实时
SqoopApacheHadoop生态大数据场景与Hadoop集成好学习成本高

6.2 读写分离实现方案

6.2.1 应用层读写分离
/*** 应用层读写分离实现*/
@Service
public class UserService {@Autowired@Qualifier("masterDataSource")private DataSource masterDataSource;@Autowired@Qualifier("slaveDataSource") private DataSource slaveDataSource;// 写操作使用主库@Transactionalpublic void createUser(User user) {// 自动路由到主库userMapper.insert(user);}// 读操作使用从库@Transactional(readOnly = true)public User getUserById(Long id) {// 自动路由到从库return userMapper.selectById(id);}
}
6.2.2 中间件读写分离
# ShardingSphere读写分离配置
spring:shardingsphere:datasource:names: master,slave0,slave1master:type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3306/master_dbslave0:type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3307/slave_db0rules:readwrite-splitting:data-sources:readwrite_ds:write-data-source-name: masterread-data-source-names: slave0,slave1load-balancer-name: round_robinload-balancers:round_robin:type: ROUND_ROBIN
读写分离方案对比
实现方式优势劣势适用场景
应用层控制精确、性能好代码侵入性强简单业务
中间件透明化、功能丰富增加复杂度复杂业务
数据库代理完全透明单点故障风险遗留系统

7. 最佳实践与避坑指南

7.1 分片键选择原则

/*** 分片键选择最佳实践*/
public class ShardingKeyBestPractices {// ✅ 好的分片键特征public void goodShardingKey() {/** 1. 数据分布均匀* 2. 查询覆盖率高* 3. 业务相关性强* 4. 更新频率低* 5. 数据类型简单*/}// ❌ 避免的分片键public void badShardingKey() {/** 1. 时间字段（数据倾斜）* 2. 状态字段（分布不均）* 3. 自增ID（热点问题）* 4. 业务无关字段* 5. 复杂计算字段*/}
}

7.2 常见问题与解决方案

跨库查询问题
/*** 跨库查询解决方案*/
public class CrossShardQuery {// 方案1：应用层聚合public List<Order> queryOrdersByUserId(Long userId) {// 确定分片List<String> shards = getShardsByUserId(userId);// 并行查询List<CompletableFuture<List<Order>>> futures = shards.stream().map(shard -> CompletableFuture.supplyAsync(() -> queryOrdersFromShard(shard, userId))).collect(Collectors.toList());// 结果聚合return futures.stream().map(CompletableFuture::join).flatMap(List::stream).collect(Collectors.toList());}// 方案2：数据冗余public void dataRedundancy() {/** 在需要跨库查询的场景下* 适当冗余数据到统一的查询库* * 优点：查询简单* 缺点：数据一致性复杂*/}
}

8. 面试要点总结

Q1: 什么情况下需要分库分表？

答案：

  1. 单表数据量过大：超过1000万条记录
  2. 查询性能下降：索引效果不明显
  3. 并发压力大：单库连接数不够
  4. 存储空间限制：单库容量达到瓶颈
  5. 业务增长快速：预期数据量快速增长

Q2: 分库分表有哪些策略？

答案：

  • 垂直分库：按业务模块拆分
  • 垂直分表：按字段拆分冷热数据
  • 水平分库：按数据特征分散到多个库
  • 水平分表：按数据量拆分到多张表

Q3: 如何选择分片键？

答案：

  1. 数据分布均匀：避免数据倾斜
  2. 查询覆盖率高：大部分查询都包含分片键
  3. 业务相关性强：与核心业务逻辑相关
  4. 更新频率低：避免频繁修改分片键
  5. 类型简单：整型或字符串类型

Q4: 分库分表后如何处理跨库查询？

答案：

  1. 应用层聚合：查询多个分片后在应用层合并
  2. 数据冗余：将需要跨库查询的数据冗余存储
  3. 中间表：创建专门的汇总表
  4. 搜索引擎：使用ES等搜索引擎
  5. 大数据组件：使用Spark、Flink等处理

Q5: ShardingSphere和Mycat的区别？

答案：

对比项ShardingSphereMycat
架构应用层框架数据库代理
功能功能丰富全面专注分库分表
性能中等较高
维护活跃缓慢
学习成本中等较低

记忆口诀

分库分表选框架，场景需求要分析；
ShardingSphere功能全，生态完善易上手；
Mycat简单性能好，中小企业首选择；
Vitess云原生架构，超大规模显威力；
数据同步有Canal，实时binlog是利器；
读写分离提性能，主从架构要配齐；
分片键选择要谨慎，数据均匀是关键；
跨库查询需优化，冗余聚合两手抓。

总结

架构师老王：选择分库分表方案需要综合考虑：

  1. 数据规模：千万级、亿级、十亿级对应不同方案
  2. 团队能力：技术水平决定了方案的复杂度
  3. 业务场景：OLTP、OLAP、混合场景有不同要求
  4. 运维成本：考虑长期的维护和扩展成本

ShardingSphere师傅：功能全面，适合大多数场景！

Mycat大师：简单稳定，传统企业的好选择！

Vitess长老：云原生时代，我是未来趋势！

记住：没有最好的方案，只有最适合的方案！

分库分表，让数据库性能飞起来！ 🚀

📌 行动指南

  1. 点赞 → 让更多Java开发者掌握数据库技术
  2. 评论 → 留言"数据库技术"领取[MySQL性能优化指南]
  3. 关注 → 追踪更新《分布式事务解决方案》（已写完待发布）
  4. 赞赏 → 解锁完整源码+专属技术咨询

🚀 下期预告
《分布式事务解决方案》关注可抢先看

📚 相关推荐：

  • 漫画Java基础
  • 漫画Spring全家桶
  • 漫画JVM调优

让我们一起在Java的世界里探索更多精彩内容！ 🚀

http://www.lryc.cn/news/586307.html

相关文章：

  • IDEA中一个服务创建多个实例
  • 李宏毅（Deep Learning）--（三）
  • Git企业级开发（多人协作）
  • 网络编程员工管理系统
  • 商业机密保卫战：如何让离职员工带不走的客户资源？
  • 独立开发第二周：构建、执行、规划
  • 手把手教你用YOLOv10打造智能垃圾检测系统
  • 从OpenMV到执行器：当PID算法开始“调教”舵机
  • 微服务环境下的灰度发布与金丝雀发布实战经验分享
  • 数据分析库 Pandas
  • 【离线数仓项目】——电商域DWD层开发实战
  • AI之DL之VisualizationTool：ai-by-hand-excel的简介、安装和使用方法、案例应用之详细攻略
  • 用 Python 将分组文本转为 Excel：以四级词汇为例的实战解析
  • Ether and Wei
  • 实用技巧 Excel 与 XML互转
  • Python ExcelWriter详解：从基础到高级的完整指南
  • Flink创建执行环境的三种方式，也是Flink搭建程序的第一步
  • Python数据容器-集合set
  • 学习笔记 Datewhale MCP Server Task2
  • 【Redis实战】Widnows本地模拟Redis集群的2种方法
  • 【嵌入式】51单片机学习笔记-Keil5软件安装教程
  • 启动Haproxy失败，如何排查问题
  • 深度聚焦：潜在学员转化与流失管理——提升销售流程闭环
  • C语言＜数据结构-单链表＞（收尾）
  • 缓存三剑客解决方案
  • BaseDao 通用查询方法设计与实现
  • Raft 代码分析
  • 区块链平台之以太坊深入解读：技术、经济与生态的全面解析
  • el-tree 懒加载 loadNode
  • 可穿戴智能硬件在国家安全领域的应用