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对应的全局事务对应的所有的分支事务提交或回滚。