分库分表太坑啦！

最新推荐文章于 2024-04-28 22:24:25 发布

白泽-默

最新推荐文章于 2024-04-28 22:24:25 发布

阅读量1.3k

点赞数 3

分类专栏： MySQL 文章标签：数据库 mysql java

本文链接：https://blog.csdn.net/qq_35462834/article/details/128190503

版权

MySQL 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

最近了解了一下分库分表，看完之后的感悟就是，能不用就不用！！一用就会有超多问题，果然每个技术不仅有优点而且背后都是有超级大的成本的，接下来我就来分享一下分库分表。

数据库分库分表后带来的优点和缺点

分库分表解决的现状问题

解决数据库本身瓶颈

连接数: 连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因
- - Mysql默认的最大连接数为100.可以修改，而mysql服务允许的最大连接数为16384
  - 数据库分表可以解决单表海量数据的查询性能问题
  - 数据库分库可以解决单台数据库的并发访问压力问题
解决系统本身IO、CPU瓶颈

- 磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢
- 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变⻓
- CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、锁等待等原因

分库分表带来新的问题

问题一：跨节点数据库Join关联查询和多维度查询

- 数据库切分前，多表关联查询，可以通过sql join进行实现
- 分库分表后，数据可能分布在不同的节点上，sql join带来的问题就比较麻烦
- 不同维度查看数据，利用的partitionKey是不一样的

- - 例如

- - - 订单表的partionKey是user_id，用户查看自己的订单列表方便
    - 但商家查看自己店铺的订单列表就麻烦，分布在不同数据节
问题二:分库操作带来的分布式事务问题
- 操作内容同时分布在不同库中，不可避免会带来跨库事务

问题三，即分布式事务问题三:执行的SQL排序、翻⻚、函数计算问题

- 分库后，数据分布再不同的节点上，跨节点多库进行查询时，会出现limit分⻚、order by排序等问题
- 而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序(也会带来更多的CPU/IO资源损耗)

问题四:数据库全局主键重复问题

- 常规表的id是使用自增id进行实现，分库分表后，由于表中数据同时存在不同数据库中，如果用自增id，则会出现冲突问题

问题五:容量规划,分库分表后二次扩容问题

- 业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容

问题。。。

OK！相信大家看完这么多问题，头都快大了叭，咱们先轻松一下，看看啥是分库分表

【垂直分表-垂直分库】

需求:商品表字段太多，每个字段访问频次不一样，浪费了IO资源，需要进行优化
垂直分表介绍

- 也就是“大表拆小表”，基于列字段进行的
- 拆分原则一般是表中的字段较多，将不常用的或者数据较大，⻓度较⻓的拆分到“扩展表如text类型字段
- 访问频次低、字段大的商品描述信息单独存放在一张表中;
- 访问频次较高的商品基本信息单独放在一张表中
- 垂直拆分原则

- - 把不常用的字段单独放在一张表;
  - 把text，blob等大字段拆分出来放在附表中;
  - 业务经常组合查询的列放在一张表中

需求:C端项目里面，单个数据库的CPU、内存⻓期处于90%+的利用率，数据库连接经常不够，需要进行优化
垂直分库讲解

- 垂直分库针对的是一个系统中的不同业务进行拆分，数据库的连接资源比较宝贵且单机处理能力也有限
- 没拆分之前全部都是落到单一的库上的，单库处理能力成为瓶颈，还有磁盘空间，内存等限制
- 拆分之后，避免不同库竞争同一个物理机的CPU、内存、网络 IO、磁盘，所以在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈
- 垂直分库可以更好解决业务层面的耦合，业务清晰，且方便管理和维护
- 一般从单体项目升级改造为微服务项目，就是垂直分库

【水平分表-水平分库】

需求:当一张表的数据达到几千万时，查询一次所花的时间⻓，需要进行优化，缩短查询时间
都是大表拆小表

- 垂直分表:表结构拆分
- 水平分表:数据拆分

水平分表

- 把一个表的数据分到一个数据库的多张表中，每个表只有这个表的部分数据
- 核心是把一个大表，分割N个小表，每个表的结构是一样的，数据不一样，全部表的数据合起来就是全部数据
- 针对数据巨大的单张表(比如订单表)，按照某种规则 (RANGE,HASH取模等)，切分到多张表里面去但是这些表还是在同一个库中，所以单数据库操作还是有IO 瓶颈，主要是解决单表数据量过大的问题
- 减少锁表时间，没分表前，如果是DDL(create/alter/add等) 语句，当需要添加一列的时候mysql会锁表，期间所有的读写操作只能等待

需求:高并发的项目中，水平分表后依旧在单个库上面，1个数据库资源瓶颈 CPU/内存/带宽等限制导致响应慢，需要进行优化
水平分库

- 把同个表的数据按照一定规则分到不同的数据库中，数据库在不同的服务器上
- 水平分库是把不同表拆到不同数据库中，它是对数据行的拆分，不影响表结构
- 每个库的结构都一样,但每个库的数据都不一样，没有交集，所有库的并集就是全量数据
- 水平分库的粒度，比水平分表更大

好！看完了基础的啥是分库分表，咱要直面狂风暴雨了，首当其冲的就是，当使用了用户的uiserId当成PartitionKey分库分表后，用户想要查看订单列表非常简单，只需要用自己的用户id取模一下，就能找到所有的订单是哪个库，那个表，但是，可怜的商家呢，他完全没法知道所有买了他辛辛苦苦卖出去商品的用户ID，那么他用啥来取模，找到自己卖出去的商品订单呢！

解决方式一【NONOSQL方案】

订单表的partionKey是user_id，用户查看自己的订单列表方便
订单数据在ES上冗余一份，让商家去ES查

解决方式二【冗余双写方案】

既然！一个partionKey满足不了需求，那么非常简单，直接整两个partionKey
拆分买家库和卖家库

- 买家库，按照用户的id来分库分表
- 卖家库，按照卖家的id来分库分表

数据冗余

- 下订单的时候写两份数据
- 在买家库和卖家库各写一份

OK！这两种方案一出来，看起来冗余双写方案会更好一点，但是其实还是要看业务，哈哈哈哈哈，冗余双写的方案没有过多的中间件节点，越少！系统越稳定，而且ES太吃内存啦，要好多钱钱。不过选择具体的技术方案的时候一定要结合业务哦。

方案敲定了，那么随之而来的又是一个大问题，分布式的事务咋解决？？？

好～在说解决方案之前，老规矩，啥是分布式事务呢，为啥就会有分布式事务的问题嘞？

什么是分布式事务

什么是分布式事务

- 事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销
- 一个是本地事务:

- - 本地事物其实可以认为是数据库提供的事务机
  - 一个是分布式事务
  - 分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性
产生的原因业务发展，数据库的拆分-分库分表 SOA和微服务架构的使用
多个微服务之间调用异常

- 网络异常、请求超时、数据库异常、程序宕机等

分布式事务下数据最终一致性-CAP的权衡结果 BASE理论

什么是Base理论

- CAP 中的一致性和可用性进行一个权衡的结果，核心思想就是: 我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性, 来自 ebay 的架构师提出

Basically Available(基本可用)

- 假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响，比如RT是10ms，变成 50ms

Soft state(软状态)

- 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时

Eventually consistent(最终一致性)
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值
关于数据一致性

- 强一致:操作后的能立⻢一致且可以访问
- 弱一致:容忍部分或者全部访问不到
- 最终一致:弱一致性经过多一段时间后，都一致且正常

分布式事务的常⻅解决方案

常⻅分布式事务解决方案

- 2PC 和 3PC

- - 两阶段提交, 基于XA协议

- TCC

- - Try、Confirm、Cancel

- 事务消息

- - 最大努力通知型

分布式事务分类

- 刚性事务:遵循ACID
- 柔性事务:遵循BASE理论

刚性事务模型

在分布式系统中，每一个机器节点能够明确知道自己在进行事务操作过程中的结果是成功还是失败，但无法直接获取到其他分布式节点的操作结果

当一个事务操作跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，

需要引入一个“协调者”(TM)来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为 AP。

TM 负责调度 AP 的行为，并最终决定这些 AP 是否要把事务真正进行提交到(RM)

两阶段提交 2PC流程解析

准备阶段:

- 事务管理器给每个参与者都发送Prepared消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。

- - Undo日志是记录修改前的数据，用于数据库回滚
  - Redo日志是记录修改后的数据，用于提交事务后写入数据

提交阶段:

- 如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息,否则发送提交(Commit)消息;
- 参与者根据事务管理器的指令执行【提交】或者【回滚】操作，并释放事务处理过程中使用的锁资源

注意:必须在最后阶段释放锁资源。

刚性事务总结

XA协议简单，数据库支持XA协议，开发使用成本比较低
对业务侵入很小，最大的优势就是对使用方透明
用户可以像使用本地事务一样使用基于 XA 协议的分布式事务，能够严格保障事务ACID 特性
事务执行过程中需要将所需资源全部锁定，也就是俗称的刚性事务

- 刚性事务:遵循ACID
- 柔性事务:遵循BASE理论

性能不理想，占用锁资源比较多，高并发常⻅下无法满足

柔性事务模型

什么是TCC柔性事务

- 刚性事务:遵循ACID
- 柔性事务:遵循BASE理论
- TCC:

将事务提交分为

- Try:完成所有业务检查( 一致性 ) ，预留必须业务资源( 准隔离性 )
- Confirm :对业务系统做确认提交，默认 Confirm阶段不会出错的即只要Try成功， Confirm一定成功
- Cancel : 业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放, 进行补偿性
- TCC 事务和 2PC 的类似，Try为第一阶段，Confirm - Cancel为第二阶段，它对事务的提交/回滚是通过执行一段 confirm/cancel 业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑