读写分离与分库分表，分布式事务

Bertha 。 2022-10-05 13:49 224阅读 0赞

## 读写分离与分库分表，分布式事务 ##

*  MySql存储引擎，建表规范，事务级别，sql优化，读写分离思想等。
 *  了解过读写分离吗？ 你说读的时候读从库，现在假设有一张表User做了读写分离，然后有个线程在一个事务范围内对User表先做了写的处理，然后又做了读的处理，这时候数据还没同步到从库，怎么保证读的时候能读到最新的数据呢？
 *  你如何保证系统的稳定性？ 答：分布式的链路一般都很长，所以我们首先通过全链路压测，分析整个链路，到底是哪个节点出现瓶颈。如果是数据层出现瓶颈，那么可以考虑加缓存，读写分离等降低数据库压力，如果短期流量很大，一天就能打满一个库，那么要考虑扩库。数据层如果没问题，瓶颈在应用层，那么需要先分析应用代码是否有问题，jvm是否可调优，线程池是否可调优，rpc超时时间设置是否正确，如果应用代码没问题，那么可以加docker，进行水平扩容。如果问题不在己方链路，在于依赖服务，那么要推进对方进行性能优化，并且最好降级预案。如果系统已经最优，无法进行优化仍然承受不了流量，那么只能做限流处理了。然后又介绍了一些流量隔离等等业内解决方案。
 *  数据库插入和删除一条数据的过程在底层是如何执行的，项目里配置了读写分离，也会比较深入的就实现方法和底层逻辑展开讨论；
 *  redis是怎么部署的？主从部署？有了解过redis集群部署吗？我说redis集群部署没有了解过，但是有了解过mysql的集群部署，有读写分离部署，主从复制，分库分表等相关方案
 *  在数据库读写分离的时候怎么做，有什么样的框架；
 *  MySQL数据量太大怎么办，如何分库分表 binlog，读写分离，主从复制 MySQL里的锁了解吗
 *  分库分表 聚合查询 limit怎么实现 top的实现 不停机扩容？分表避免冷热？不停机扩库？不停机扩表？跨库事务？ 分库分表为什么这么设计？数据增长怎么做？怎么扩容？数据不均匀怎么办？冷热数据怎么分离？聚合怎么做？跨库聚合怎么做，查询怎么做？跨库分页怎么做？ mysql 线上的组群模式？一主多从？为什么这样？强一致性如何保证？为了解决读写分离吗？是为了一主多备吗？主库crash掉怎么办？从库呢？ 分布式事务怎么做？什么原理？怎么实现的？出现过事务不一致性吗？为什么？怎么解决的？ 访问请求暴增怎么做？怎么缓解压力？
 *  如何实现 MySQL，事务隔离级别，什么时候脏读，什么时候读已提交 分布式事务（经常被问到） 1、两阶段提交（2PC） 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交. 第二阶段：事务协调器要求每个数据库提交数据。 优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致） 缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景 2、补偿事务（TCC） 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）。Try、Confirm、Cancel 优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些 缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。 3、本地消息表（异步确保） 核心思想是将分布式事务拆分成本地事务进行处理，消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。 优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。 缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。 4、MQ事务消息 RocketMQ支持，RabbitMQ 和 Kafka 都不支持，一次发送消息和一次确认消息，生产方需要实现一个check接口（确认消息或者回滚） 优点： 实现了最终一致性，不需要依赖本地数据库事务。 缺点： 实现难度大，主流MQ不支持，没有.NET客户端，RocketMQ事务消息部分代码也未开源。 5、Sagas事务模型 长时间运行的事务，该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。
 *  关于分布式事务、以及分布式事务问题------ 关于分库分表（为什么要分库分表，用过哪些分库分表中间件）---- 分库分表的方法-----------结合项目，垂直和水平拆分 如何设计动态扩容缩容的分库--- 分库分表全局ID如何生成
 *  分库分表是以什么维度来划分的？划分的算法是怎样的，会不会出现数据分配不均衡的情况。 myisam和innodb支持锁的粒度是怎样的？
 *  5、订阅分库分表的 Binlog 怎么订阅？ 6、分库分表的数据源中假如存在主键冲突要怎么解决？ 7、怎么保证下游对 Binlog 的消费顺序？ 8、如何在下游保证消费时的事务原子性？
 *  假如用 id 翻页的方式, 数据库表如何设计? 索引如何设计? 5. 假如量很大, 你觉得需要分库分表吗? 怎么分? 6. 分库分表后怎么查询分页? 7. 分库分表后怎么保证主键仍然是递增的? 8. 现在需要支持深分页, 页码直接跳转, 怎么实现? 9. 瞬时写入量很大可能会打挂存储, 怎么保护?
 *  分库分表带来的问题。
 *  分库分表怎么做（要方案）
 *  mysql 怎么做的分库分表，有没有遇到跨库查询问题 某个分库数据量特别大的情况，怎么解决 mysql 慢查询怎么解决的，explain怎么使用，重点关注哪里 分库分表，线上数据量有多大 数据库连接池怎么设计的 定时任务，数据量会不会特别大
 *  oracle跟mysql的区别，隔离级别 慢查询如何定位？如何优化？遇见过什么样的case，怎么解决的？ 项目用到了分库分表，分库一定会提升性能呢？什么是冷热数据？优化了什么地方？假如出现了数据暴增，怎么处理？有什么扩容的方法？怎么无感知扩容？怎么做到数据实时一致性？ 分库分表的设计？ 分布式事务出现过不一致吗？为什么？怎么解决？有什么方法避免？怎么监控？监控到怎么处理？什么时候需要人工接入。分库分表 聚合查询 limit怎么实现 top的实现 不停机扩容？分表避免冷热？不停机扩库？不停机扩表？跨库事务？ 分库分表为什么这么设计？数据增长怎么做？怎么扩容？数据不均匀怎么办？冷热数据怎么分离？聚合怎么做？跨库聚合怎么做，查询怎么做？跨库分页怎么做？ mysql 线上的组群模式？一主多从？为什么这样？强一致性如何保证？为了解决读写分离吗？是为了一主多备吗？主库crash掉怎么办？从库呢？ 分布式事务怎么做？什么原理？怎么实现的？出现过事务不一致性吗？为什么？怎么解决的？ 访问请求暴增怎么做？怎么缓解压力？
 *  mysql唯一索引能加入null吗（不会） innodb特性 mysql回表 mysql分库分表标准？
 *  如何分库分表，分页查询，查询非拆分字段方案； MySql索引结构，为什么用B+树（对比Hash，B+树，B树，AVL，红黑树）；
 *  分库分表怎么做？基于什么维度去做？
 *  列举出你能想到的数据库分库分表策略；分库分表后，如何解决全表查询的问题
 *  聊聊对事务的理解（什么是事务？事务的特性？） 事务的隔离级别 InnoDB 和 MyISAM 的区别？ 如何优化慢 SQL? 一亿的表，很多复杂的查询条件，查第一万页，如何优化？分库分表查询过程？ 二阶段、三阶段、TCC、seata
 *  设计一个系统，每天有100亿条数据，需要在后台做实时展示和查找。 我当时回答的大体思路是nginx负载均衡，消息队列存储，多线程读取，批量插入，数据库分库分表。 面试官根据我的回答又衍生出了很多问题，如消息队列存满了怎么办？（也就是消费跟不上生产）批量插入时某一条失败了有什么影响？怎么解决？分库分表应该怎么分？怎么解决数据迁移的问题？
 *  分库分表的实现原理是什么，你所在业务一般是怎么分库分表的？对应逻辑是什么？
 *  mysql分库分表原则，为什么要分这么多库这么多表，基于什么考虑？数据库3、动态扩容要如何实现？
 *  问分库分表优化
 *  •乐观锁和悲观锁的区别？ •这两种锁在Java和MySQL分别是怎么实现的？用的什么数据库？ •使用什么存储引擎，为什么使用InnnoDB？ •订单表有做拆分么，怎么拆的？ •水平拆分后查询过程描述下 •如果落到某个分片的数据很大怎么办？ •哈希取模会有什么问题么？ •分库分表后怎么解决读写压力？ •拆分后主键怎么保证惟一？ •Snowflake生成的ID是全局递增唯一么？ •怎么实现全局递增的唯一ID？ •Mysql的索引结构说下 •主键索引和普通索引的区别？ •你们系统目前的瓶颈在哪里？ •你打算怎么优化？简要说下你的优化思路 •有什么想问我么？
 *  一. 数据库 1.使用mysq1索引都有哪些原则?索引什么数据结构?B+tree和Btree什么区别? 2.mysq有哪些存储引擎啊?都有啥区别? 3.设计高并发系统数据库层面该怎么设计?数据库锁有哪些类型?如何实现呀? 4.数据库事务有哪些? 二. 分库分表 1.如何设计可以动态扩容缩容的分库分表方案? 2.用过哪些分库分表中间件,有啥优点和缺点， 3.讲一下你了解的分库分表中间件的底层实现原理? 4.我现在有一个未分库分表的系统,以后系统需分库分表,如何设计， 5.让未分库分表的系统动态切换到分库分表的系统上? 6.分布式事务知道吗?你们怎么解决的?TCC?那若出现网络原因,网络连不通怎么办啊 7.为什么要分库分表啊? 8.分布式寻址方式都有哪些算法?知道一致性hash吗? 9.手写一下java实现代码?你若userId取摸分片,那我要查段连续时间里的数据怎么办? 10.如何解决分库分表主键问题?有什么实现方案?
 *  1、分布式事务 2、主键索引和唯一索引区别 3、hash索引和B+树索引区别及使用场景 4、单列索引和复合索引使用场景 5、应用内存溢出怎么排查 6、MYSQL执行计划怎么查看，以及应该关注哪些字段 7、分库分表时，怎么实现多表查询 8、亿级数据怎么存储
 *  分库分表如何做的？ 分库分表如何不同库表间数据不重复。
 *  分库分表如何选择分表键 分库分表的情况下，查询时一般是如何做排序的？
 *  能否举个业务上的例子说说分库分表？----------这是针对并发量过大导致单机存储容量、连接数、处理能力瓶颈问题。垂直切分也分为分库和分表两种措施，垂直分库是根据业务耦合性关联度较低的不同数据存储到不同的数据库中，比如客户信息库、商品信息库……分开存放到不同的库中。垂直分表是基于原数据表的字段太多而拆分的方式，比如客户表有个人身份属性，地址联系等属性……。水平切分分为库内分表和分库分表，将同一个表的数据按照不同的条件分配到多个表中，比如ID奇偶分表。库内分表只解决了单一表数据过大的问题，没有将表分布到不同的机器上，所以为了避免竞争同一台机器的CPU、内存、网络等可以分布到不同的库中。 分库分表带来的问题又是什么？---------事务一致性的问题；跨机器节点关联问题；跨节点分页排序问题；全局主键避重问题；数据迁移扩容问题
 *  分库分表应该怎么分？怎么解决数据迁移的问题？
 *  关于分布式事务、以及分布式事务问题------ 关于分库分表（为什么要分库分表，用过哪些分库分表中间件）---- 分库分表的方法-----------结合项目，垂直和水平拆分 如何设计动态扩容缩容的分库--- 分库分表全局ID如何生成
 *  你们数据库有没有用到分库分表，怎么做的？分库分表以后全局id怎么生成的？
 *  你们公司对分库分表，避免热点是怎么处理的？----------这涉及到数据库瓶颈问题的解决，所以要结合项目，对数据进行垂直和水平拆分。水平分库：（可以手动画个草图来阐述）当用户通过userId来请求数据，通过对userId的分析得出该去哪个数据库进行操作（比如：A数据库是偶数userId,B数据库是奇数userId。不仅仅是通过userId也有按照其他分库的方式，每个库的结构一样，但数据不一样）。水平分表：做法和分库是一样的。垂直分库：依照业务的不同，拆分成多个数据库（用户数据库和产品数据库……各管各的），垂直分表就是依照uid为核心，将字段分割（比如表一存放个人身份信息姓名年龄……，表二存放个人社交信息联系方式地址……） 除了分库分表，你还了解些MySQL什么优化？
 *  mysql分库分表原则 - 为什么要分这么多库这么多表 - 基于什么考虑？ - 如何实现数据库动态扩容？
 *  分布式事务了解吗？有哪几种解决方案？
 *  mysql 幻读和间隙锁 分片实现事务，mysql原生实现分布式事务
 *  常见的分布式事务方案有哪些？ （1）两阶段提交方案 （2）eBay 事件队列方案 （3）TCC 补偿模式 （4）缓存数据最终一致性
 *  你的项目中，如何保证分布式事务的一致性
 *  为什么选择本地消息法做分布式事务？ 什么是TCC，它的工作过程？ TCC 和 XA 的区别？ 如果让你优化XA，你会如何优化？
 *  分布式事务了解吗？你们项目中都用到了哪些分布式事务？都有哪些优缺点？
 *  分布式事务的原理，如何使用分布式事务
 *  秒杀系统，会涉及到多个库表的更新，分布式事务怎么解决，我说的消息最终一致性，异步？有没有更好的方案？同步TCC方式，TCC方式原理？（三个阶段的具体实现）
 *  从秒杀系统还引申出分布式事务的几种实现，二段式、三段式、补偿型(TCC)、基于可靠消息服务的消息队列实现。重点讨论了这几种的实现和区别，要求画出基于可靠消息服务的消息队列实现分布式事务的架构图，以及上游服务和下游服务如何保证消息可靠性和一致性。
 *  其实归根到底就是分布式事务的数据一致性解决方案，失败了数据怎么回滚
 *  分布式事务如何保证？
 *  分布式事务的原理，如何使用分布式事务
 *  以及分布式事务理论和解决方案
 *  MySQL索引原理、联合索引、索引注意事项、慢查询排查 雪花算法原理 MySQL IN的原理，如何优化 分库分表如何操作 分布式事务的几种形式
 *  对分布式事务的理解
 *  一. 数据库 1.使用mysq1索引都有哪些原则?索引什么数据结构?B+tree和Btree什么区别? 2.mysq有哪些存储引擎啊?都有啥区别? 3.设计高并发系统数据库层面该怎么设计?数据库锁有哪些类型?如何实现呀? 4.数据库事务有哪些? 二. 分库分表 1.如何设计可以动态扩容缩容的分库分表方案? 2.用过哪些分库分表中间件,有啥优点和缺点， 3.讲一下你了解的分库分表中间件的底层实现原理? 4.我现在有一个未分库分表的系统,以后系统需分库分表,如何设计， 5.让未分库分表的系统动态切换到分库分表的系统上? 6.分布式事务知道吗?你们怎么解决的?TCC?那若出现网络原因,网络连不通怎么办啊 7.为什么要分库分表啊? 8.分布式寻址方式都有哪些算法?知道一致性hash吗? 9.手写一下java实现代码?你若userId取摸分片,那我要查段连续时间里的数据怎么办? 10.如何解决分库分表主键问题?有什么实现方案?
 *  6、分布式事务的解决方案？ 一、两阶段提交（2PC） 两阶段提交（Two-pha\*\*\*mit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 准备阶段：协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 提交阶段：如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 二、补偿事务（TCC） TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段： Try 阶段主要是对业务系统做检测及资源预留 Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。 三、本地消息表（异步确保） 本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。 之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。 四、MQ 事务消息 第一阶段Prepared消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。 答案只是个人的一些观点，有不对的欢迎指出来。
 *  分布式事务的各种方案及你的最佳方案
 *  分布式事务（经常被问到） 1、两阶段提交（2PC） 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交. 第二阶段：事务协调器要求每个数据库提交数据。 优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致） 缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用，目前 .NET 界还没有实现方案。 2、补偿事务（TCC） 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）。Try、Confirm、Cancel 优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些 缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。 3、本地消息表（异步确保） 核心思想是将分布式事务拆分成本地事务进行处理，消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。 优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。

> 欢迎搜索关注本人的公众号【微瞰技术】,以及总结的分类面试题[https://github.com/zhendiao/JavaInterview][https_github.com_zhendiao_JavaInterview]

![file][]

[https_github.com_zhendiao_JavaInterview]: https://github.com/zhendiao/JavaInterview
[file]: /images/20221005/f9d51a256092499288e51edc8bf8bc17.png