Skip to content

flystar32/DistributedTrans

Repository files navigation

Undo Log

Undo Log 是为了实现事务的原子性,主要记录的是一个操作的反操作的内容。

  • 事务的原子性(Atomicity)
    一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。
    事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。

  • 事务的持久性(Durability)
    事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

  • 用Undo Log实现原子性和持久化的事务的简化过程

      假设有A、B两个数据,初始值分别为1和2。现在需要执行一个事务,将A的值改为3且将B的值改为4。  
    
      A.事务开始.   
      B.记录A=1到undo log的内存buffer.   
      C.在内存中修改A=3.   
      D.记录B=2到undo log的内存buffer.   
      E.在内存中修改B=4.   
      F.将undo log的buffer写到磁盘。  
      G.将内存中修改后的数据写到磁盘。  
      H.将事务标记为已提交的状态
    

这整个过程中,有可能出现异常情况。在目前的系统中,我们认为异常情况有两种:
一正常的逻辑已经无法继续下去,但是程序本身还是可以正常运行的,可以依靠程序本身的异常处理逻辑来处理这部分异常。
第二种异常比较严重,程序本身已经无法正常工作了,比如系统突然断电。
为了便于叙述我们将前者称为逻辑异常,后者称为宕机异常。

  • 如果在A到F的过程中出现了逻辑异常,数据库会将此次的事务表示为失败的状态,因为G并没有执行,所以数据还是原样不动,符合一致性。
  • 如果在G到H的过程中出现了逻辑异常,数据库会将此次的事务表示为失败的状态,当发现G已执行后,会执行F中保存的undolog,将数据恢复。
  • 如果在A到E的过程中出现了宕机异常,数据库重启后会发现这个事务处于初始状态,但是没看到undolog,说明G肯定没执行,数据是一致的,可以放心地直接将事务标记为失败。
  • 如果在F到H的过程中出现了宕机异常,数据库重启后会发现这个事务处于初始状态,然后一看,undolog是存在的,这个时候就尴尬了,G到底执行成功了没有呢?,如果未执行成功,则数据现在就是一致的,直接将事务标记为失败就好,如果执行成功了,则需要执行undolog将数据恢复成一致的状态,这可如何是好?

这里需要引入一个redolog,就是将之前的更新A和更新B的操作也记录下来,只要这个redolog的执行可以保证幂等性,之前苦恼的问题就解决了,也不需要猜测这个G是否真正的执行成功了,只需要将redolog重新执行一遍即可。然后就可以放心地执行undolog,将数据恢复一致性后再将事务标记成失败的状态。
幂等是一个很好的词语,我们在设计自己的系统时候,可以很轻松地通过请求流水号等参数将幂等实现。但是对于数据库来说,因为对性能的要求比较高,所以幂等有可能不成立。(这一点我不确定,我猜测的,支持幂等最好)

回到上文中的顺序,其实F和G这两步骤,在每一个的事务执行的过程中,都需要强行地写两次磁盘。这样会导致大量的磁盘IO,因此性能很低。

综合这两点来说,redolog是避免不掉的,而且既然已经有redolog了,是否就可以不再需要将数据实时写到磁盘这一步,大不了奔溃的时候,直接使用redolog将数据恢复。

    A.事务开始.
    B.记录A=1到undo log的内存buffer.
    C.内存中修改A=3.
    D.记录A=3到redo log的内存buffer.
    E.记录B=2到undo log的内存buffer.
    F.内存中修改B=4.
    G.记录B=4到redo log的内存buffer.
    H.将undo log的buffer写到磁盘。
    I.将redo log的内存buffer写入磁盘。
    J.事务提交

虽然数据不需要时写磁盘了,但是undolg和redolog还是需要写,看起来并没有什么改观?
但是有个不一样的是,数据库的数据是结构化存储的,存储位置早就确定了,而且大多数是更新请求。
但是redolog和undolog都是新的内容,对他们来说,保存就是新增文件。
再联想到kafka为什么写文件效率那么高,磁盘的顺序写操作其实是非常快的,并不比内存满多少。
而且既然想要实现顺序写,就干脆把undolog也作为redolog的内容的一部分进行保存。

顺序写,就表明了这个过程中,redolog可能是逻辑无关的,很多分别属于不同事务的redolog会被一起写到磁盘上,当系统在出现宕机异常时,会找到数据保存的那个checkpoint,然后开始执行之后的redolog,将数据恢复。
如果执行了尚未被标记为成功的事务,或者执行了已经被标记为Rollback的事务,这时候会去找到他们的undolog,执行undolog后,将数据恢复到一致的状态。

详细的流程这里就不再讲了,涉及到mvcc的更加复杂,我也尚未完全弄清楚,可以参考以下文章:
InnoDB recovery详细流程
MySQL · 引擎特性 · InnoDB 崩溃恢复过程

分布式事务

回到刚才的问题,之所以做了那么多的扩展,是因为遇到了前面说的那个问题,无法确定将undo log的buffer写到磁盘执行成功后,将内存中修改后的数据写到磁盘是否执行成功,如果解决了这个问题,也就没redolog啥事了。

我们在执行分布于不同的两个数据库的操作时,数据库的事务已经无法使用了,但是对于单个数据库来说了,数据库的事务还是很有效的,而且对于我们应用层的框架来说,也不会那么纠结于性能,毕竟网络IO会占大多数。
想到这里,我们可以使用数据库的事务来保证数据A操作的do操作和undolog的保存在同一个事务中!

因为我们主要的业务是做支付,那么我们就将A转账给B这个场景来进行讨论

如图所示,distributeJob代表了一个完整的转账场景,A转账10元给B,其中A和B的账户存储在不同的数据库中,执行的过程是先通过transferOut从A的账户中扣除10元,然后再执行transferIn给B增加10元。

undoOutSave,表明将transferOut的undolog保存起来,方便在需要rollback时将transferOut的影响撤销,在这里其实就是将钱加回来,即给A的账户增加10元。同理对于transferIn的undolog的保存也就是undoInSave。
其中绿色的框框将两个操作框起来,是表明这两个操作是位于同一个数据库事务中。

当执行过程中出现异常时,会将之前所有已完成的操作回滚,恢复到初始状态,一个比较通用的整体的流程如下

因为我们是使用thrift框架来做服务的,整个过程使用拦截器来实现各种逻辑,最外层代码看起来如下

@DistributeJob
public boolean transfer(Context context, String fromId, String toId, long amount) throws TException {
  try {
    transferOut(context, fromId, toId, amount);
    transferIn(context, fromId, toId, amount);
  } catch (Exception e) {
    throw new TException(e);
  }
  return true;
}


@DoJob
@GetConnection
public boolean transferOut(Context context, @SharedKey("userId") String fromId, String toId,
                           long amount) throws Exception {
  userDao.updateBalanceById(context.getConnection(), fromId, -amount, 0L);
  undoTransferOut(context, null, fromId, toId, amount);
  return true;
}

@UndoJob
@GetConnection
public boolean undoTransferOut(Context context, com.xiaojing.distributed.model.UndoJob undoJob,
                               @SharedKey("userId") String fromId, String toId, long amount)
  throws Exception {
  userDao.updateBalanceById(context.getConnection(), fromId, amount, Long.MIN_VALUE);
  return true;
}

看不懂也没关系,下面有详细的流程图。

红色的线表明,所有被抛出的逻辑异常都会触发在线的回滚。这里叫逻辑异常也不全,也有可能是网络异常导致的IO异常,这里我们换个说法,将这些异常统称为,非宕机异常。

同样的,如前文所说,还有一种异常叫做宕机异常,在解决这些异常时,没有在线回滚了,只能在服务重启后,通过扫表的方式来进行离线的回滚。离线回滚无非就是线找到未完成的事务,然后将其的undolog找出来,然后执行undolog即可。

如前文所说的,undolog执行的幂等还是很重要的,在这里我们是通过将undolog置为rollbacked和执行undolog的内容放在同一个事务中来保证,undolog只会执行一次的。

在出现异常的时候,回滚的流程图如下。

图中的rollback fail,极少数情况下会发生,比如B账户注销了,或者是B账户的钱恰好在这一刻完全花完了,这种情况,只好交给人工处理。

测试

1、代码中的test目录下,模拟了各种情况下出现的非宕机异常,验证了结果的有效性。单测中使用了h2数据库,测试前必须先将其启动。
2、对于宕机异常,写了一个shell脚本,每1s关闭服务一次,client不断去调用server执行转账操作。当停止两个脚本后,正常启动服务,最后check金额,满足一致性。执行方法如下:

mvn -Dmaven.test.skip=true clean package
nohup sh transfer_server.sh daemon &
nohup sh transfer_server.sh kill &
nohup sh transfer_client.sh start &
kill -9 (daemon/kill/client) 将服务端和客户端都停止
sh scheduler_rollback.sh start

执行前,需要将配置文件中的数据库换成自己的地址,并执行一下init.sql中的初始化语句,还有把脚本里的路径换成你自己的。
在正常服务中,scheduler_rollback不需要作为一个单独的服务进行启动,他只是main server的一个线程

在执行rollback之前,查看数据库中的数据,明显可以看出数据是不一致的

rollback服务启动一段时间后,查看数据库中账户1和2的总金额,发现是一致的。我们这里使用的是10s调度一次,通过测试数据观察,真正的回滚耗费实践是在ms级别的。

rollback执行过程中的数据distribute_job和undo_job的状态如下

小细节

1、这里是先执行了do,然后再保存undo,其实因为两者属于同一个数据库事务,先后顺序其实不那么重要。但是在逻辑异常需要回滚的时候,我们还是希望能够直接从内存里拿出undolog,然后进行undo操作的,这样可以减少一次数据库查找的开销,因为这个原因,所以将undosave放在了后面,写代码的时候比较不容易弄混。
2、小技巧,对于所有的有可能存在并发的对数据的操作,所有的读操作都是不正确的,直接使用CAS的写操作,以写代查,才是正确的做法。
3、判断一个事务是否是因为宕机停留在初始状态是通过超时来判断的,所以执行中的distributeJob需要select for update。 4、正常的服务都是无状态扩容的,虽然我们的rollback支持并发和幂等,但是为了避免过度竞争影响效率,rollback操作还是需要制定一台的执行。

局限

听起来很美妙,实现了分布式事务!遗憾的是,这套代码并没有在生产环境上使用,理由有如下:

1、真实情况下,一个交易并不仅仅是只有账户的变动,还有其他服务的调用、跨服务的rpc,而不仅仅是数据库。关于这一点,下一篇我会写写跨服务的分布式事务。
2、大多数交易出现的费宕机异常都是网络的IO异常,这种情况下完全可以通过重试解决,直接rollback的方式过于悲观,而且增加上游接入难度。
3、“分布式事务”本身的局限性,这里只对量变比较好使,对于质变这种方式,这种rollback是不是正确的呢?况且即使是做CAS也无法解决ABA的问题。

最佳使用场景,电商购物车多件商品抢购模型。因为都是量变,而且直接在失败时迅速回归库存正好适用于此场景。

参考文档

MySQL数据库InnoDB存储引擎Log漫游(1)
MySQL · 引擎特性 · InnoDB undo log 漫游
MySQL · 引擎特性 · InnoDB redo log漫游

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published