分库分表实施

项目仓库java-concurrency-security:用于学习使用的的项目。基于 Spring Boot 2.7 的高并发性能调优 安全监控完整脚手架涵盖 JVM 调优、线程池优化、Redis 缓存防护、分库分表、OAuth2.0 认证、API 网关、ELK 日志收集、SkyWalking APM 监控等核心能力。 - AtomGit | GitCode前言为什么要分库分表类比把数据库想象成图书馆。问题 1图书馆只有一个管理员借书还书的队排到街上了 → 单库连接数不够问题 2书架太多读者找书要花半小时 → 单表数据太多查询慢问题 3消防通道只能过 1 个人遇到紧急情况太危险 → 备份慢恢复慢解决方案开分馆分库每个馆多放几个书架分表让客流分散。1. 什么时候该分不要为了将来分要为现在分。过早分库分表会增加复杂度不分又扛不住业务。指标阈值说明通俗判断单表行数 500 万查询性能开始下降单本读者登记簿已经记不下了单库 QPS 3000连接池和 IO 瓶颈管理员忙不过来单库大小 100GB备份恢复时间过长整馆搬一次要花 2 小时经验法则假如你的订单表已经有 1 亿行单表查询要 10 秒 → 该分了。 如果只有 10 万行但偶尔查询慢 → 先加索引别急分。2. 水平分片按行拆分2.1 什么是水平分片类比水平分片 同一个商品分到多个货架上每个货架摆一部分。 京东商城有 10 亿件商品分布在 100 个仓库每个仓库负责 1000 万件。2.2 分片架构本项目采用2 库 × 4 表 8 张表的水平分片方案shardingSphere 是什么它像一个智能路由器 应用说我要查 user_id123 的订单它自动算出来这条数据在 ds1 的 t_order_2 表里 然后直接去那里取。应用层完全无感知。2.3 分片键选择最关键的一步分片键选错了会导致全表扫描分库分表白做标准说明反面例子高频查询选择 WHERE 条件中最常用的字段选status订单状态但实际很少按状态查数据均匀避免数据倾斜选is_vip会员标记90% 用户都是非会员避免跨片关联查询尽量在同一分片订单用 user_id 分商品用 product_id 分关联查询要扫所有库业务相关选择业务维度选create_time时间会导致数据集中在某段时间内本项目选择分库键user_id同一个用户的所有订单一定在同一个库查询订单不用跨库分表键order_id分散写入压力避免单表热点为什么用 user_id 分库而不是 order_id用户的订单查询占 80% 的请求 → 按 user_id 分可以 100% 命中单一库按 order_id 分库的话查我所有订单要扫所有库2.4 分片算法# 分库user_id 对 2 取模结果 0→ds01→ds1 # 举例user_id123123%21所以订单存到 ds1 # 分表order_id 对 4 取模结果 0~3 对应 4 张表 # 举例order_id1008610086%42所以存到 t_order_2为什么用 HASH_MOD 而不用 MOD哈希取模对连续值如 10086、10087分布更均匀 而普通取模会让相邻的 order_id 落在同一张表造成热点。2.5 分布式 ID雪花算法问题数据分散到 8 张表后ID 不能用数据库自增了 因为两个库同时自增ID 会重复。类比分布式 ID 就像给每个商品印全球唯一编码格式是 地区码 日期 流水号地球上任何地方都不会重复。1bit 符号41bit 时间戳10bit 工作机器12bit 序列号0毫秒级时间机器ID线程每毫秒序号不使用精确到毫秒区分机器每毫秒自增优势✅ 全局唯一包含时间戳机器ID序列号✅ 趋势递增按时间排序范围查询快✅ 高性能本地生成不用等数据库3. 垂直分片按列拆分3.1 垂直分库按业务域类比大公司拆分成不同部门每个部门管自己那摊事。 用户部只管用户数据订单部只管订单数据互不干扰。什么时候用垂直分库不同业务的用户群体差异很大时。 比如商品库可能要 1 万 QPS但用户库只有 100 QPS混在一起就要按最高的配。3.2 垂直分表大字段拆分类比餐厅的菜单主菜单印常点的菜爆款附加单印大菜海鲜。 主菜单薄薄的翻得快海鲜的菜单独放在最后几页。主表 t_product高频查询每次 SELECT 都用到 ├── id, name, price, stock, status -- 字段小常查询 扩展表 t_product_detail低频大字段 ├── product_id -- 关联主表 ├── description TEXT -- 商品详情几千字 ├── images JSON -- 图片列表 ├── specs JSON -- 规格参数什么时候用某条记录的某些字段特别大TEXT、BLOB、JSON 每次查询都把它们读出来很浪费慢、占 IO、占内存。4. 实施步骤4.1 数据迁移流程一句话双写→校验→切读→切写→观察→下线千万不要一次切换大厂踩过的坑 某公司双 11前想当然地一刀切结果新表分片键配置错 导致全公司订单数据错乱最后紧急回滚影响交易 4 小时。4.2 跨分片查询处理场景解决方案类比按 user_id 查订单直接路由到对应分片在指定分馆找书按 order_id 查订单先查映射表再路由不知道分馆就先查图书总目录全局搜索订单用 ES 异构索引找专业图书检索员ES跨分片分页禁止改用 ES 或游标不允许把 8 个馆的书全搬到一起数4.3 分布式事务问题订单表在订单库库存表在商品库账户表在用户库 → 怎么保证要么都成功要么都失败GlobalTransactional // Seata AT 模式自动管理分布式事务 public void createOrder(OrderDTO dto) { orderMapper.insert(order); // 订单库插入订单 inventoryService.deduct(); // 商品库扣库存 accountService.debit(); // 用户库扣余额 } // 三步要么都成功要么都回滚Seata 是什么它像一个协调员每个分库都向协调员汇报 协调员说都成功才提交说有失败就全部回滚。5. ShardingSphere 配置详解参见application.yml中的spring.shardingsphere配置节。5.1 关键配置项配置项作用类比actual-data-nodes实际的数据节点列表我们有哪些仓库database-strategy分库策略按什么分到不同仓库table-strategy分表策略仓库内怎么分货架key-generator分布式主键商品编码规则sharding-algorithms分片算法具体怎么分5.2 常见问题Q分库后还能 JOIN 吗A尽量避免。JOIN 要求扫描多个库性能极差。改为数据冗余在订单表冗余商品名称内存组装先查订单列表再批量查商品 MapES 异构索引最灵活Q分表后怎么分页A禁止LIMIT 100000, 20要扫 100020 条记录。 改用游标分页WHERE id 100020 LIMIT 20ES 全文检索后分页前端加载更多模式