01mysql
内存中的数据库数据何时持久化到磁盘？因为redolog已经持久化，因此数据库数据写入磁盘与否影响不大，不过为了避免出现脏数据（内存中与磁盘不一致），事务提交后也会将内存数据刷入磁盘（也可以按照固设定的频率刷新内存数据到磁盘中）。redolog何时写入磁盘redolog会在事务提交之前，或者redologbuffer满了的时候写入磁盘这里存在两个问题：问题1：之前是写undo和数据库数据到硬盘，现在是写undo和redo到磁盘，似乎没有减少IO次数-数据库数据写入是随机IO，性能很差-redolog在初始化时会开辟一段连续的空间，写入是顺序IO，性能很好-实际上undolog并不是直接写入磁盘，而是先写入到redologbuffer中，当redolog持久化时，undolog就同时持久化到硬盘了。因此事务提交前，只需要对redolog持久化即可。另外，redolog并不是写入一次就持久化一次，redolog在内存中也有自己的缓冲池：`redologbuffer`。每次写redolog都是写入到buffer，在提交时一次性持久化到磁盘，减少IO次数。问题2：redolog数据是写入内存buffer中，当buffer满或者事务提交时，将buffer数据写入磁盘。redolog中记录的数据，有可能包含尚未提交事务，如果此时数据库崩溃，那么如何完成数据恢复？数据恢复有两种策略：-恢复时，只重做已经提交了的事务-恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过UndoLog回滚那些未提交的事务Inodb引擎采用的是第二种方案，因此undolog要在redolog前持久化02总结
最后总结一下：-undolog记录更新前数据，用于保证事务原子性-redolog记录更新后数据，用于保证事务的持久性-redolog有自己的内存buffer，先写入到buffer，事务提交时写入磁盘-redolog持久化之后，意味着事务是**可提交**的业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。03Seata支持的事务模型
Seata会有4种分布式事务解决方案，分别是AT模式、TCC模式、Saga模式和XA模式。Seata中比较常用的是AT模式。订单服务在下单时，同时调用库存服务和用户服务，此时就会发生跨服务和跨数据源的分布式事务问题。在Seata中，将Storage服务看成一个本地事务，Business服务看成一个本地事务，将Order服务看成一个本地事务，将Account服务看成一个本地事务，其构成了一个DistributedTransaction，由TC统一协调。在Seata中称之为“GlobalTransaction”在Seata中有三个基础组件：TransactionCoordinator(TC)(协调者)：维护全局和分支事务的状态，驱动全局提交或回滚。TransactionManager(TM)(事务管理)：定义全局事务的范围，开启全局事务，提交或回滚一个全局事务。ResourceManager(RM)(资源管理)：管理分支事务资源。与TC通讯并报告分支事务状态，管理本地事务的提交与回滚。在Seata中，一个典型的生命周期如下所示：TM要求TC生成一个全局事务，并由TC生成一个全局事务XID返回。XID通过微服务调用链传播。RM向TC注册本地事务，将其注册到ID为XID的全局事务中。TM要求TC提交或回滚XID对应的全局事务。TC驱动XID对应的全局事务对应的所有的分支事务提交或回滚。