快手暑期

一面凉经
1.tcc介绍一下（见下）
https://blog.csdn.net/m0_58719994/article/details/131691392

2.事务的几种模式，
- AT、TCC、Saga、XA模式分析
- 四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景
AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。
（1）阿里seata框架，实现了该模式。
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

（2）TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
TCC 三个方法描述：
Try：资源的检测和预留；
Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
Cancel：预留资源释放；

（3）Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。
Saga模式的优势是：
- 一阶段提交本地数据库事务，无锁，高性能；
- 参与者可以采用事务驱动异步执行，高吞吐；
- 补偿服务即正向服务的“反向”，易于理解，易于实现；

（4）XA模式是分布式强一致性的解决方案，但性能低而使用较少。XA规范的基础是两阶段提交协议2PC。在XA模式下，需要有一个[全局]协调器，每一个数据库事务完成后，进行第一阶段预提交，并通知协调器，把结果给协调器。协调器等所有分支事务操作完成、都预提交后，进行第二步；第二步：协调器通知每个数据库进行逐个commit/rollback。
其中，这个全局协调器就是XA模型中的TM角色，每个分支事务各自的数据库就是RM。

原文链接：https://blog.csdn.net/ruiyiin/article/details/114633701
https://zhuanlan.zhihu.com/p/78599954

3.redo log、binlog、undolog的日志有什么区别
- redo log，一行记录就占了几十byte，只要包含了表空间号、数据页号、磁盘文件偏移量、修改值，再加上是顺序写，所以刷盘效率很高。
- binlog日志是逻辑日志，记录内容是语句的原始逻辑，属于MySQL Server层。所有的存储引擎只要发生了数据更新，都会产生binlog日志。
- MVCC的实现依赖：隐藏字段、Read View、undo log。在底层实现中，InnoDB通过数据行的DB_TRX_ID和Read View来判断数据的可见性，如不可见，则通过数据行DB_ROLL_PTR找到undo log中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事物里，用户只能看到该事务创建Read View之前已经提交的修改和该事务本身做的修改。

原文：https://blog.csdn.net/qq_34222160/article/details/124414775

4.手撕：重排链表