Transaction & Distributed Transaction(2)

[WIP] 分布式事务

原子提交:

在支持跨多节点或跨多分区事务的数据库中,一个事务可能在某些节点上失败,但在其他节
点上成功。如果我们想要维护事务的原子性(就ACID而言,请参“原子性”),我们必须让所
有节点对事务的结果达成一致:要么全部中止/回滚(如果出现任何错误),要么它们全部提
交(如果没有出错)。这个共识的例子被称为原子提交(atomic commit)问题

2PC

  • 确定提交大家都要提交

2PC

准备提交时:

  • Coordinator 阶段1:
    • 发送 Prepare, 询问是否提交
    • Coordinator 跟踪
  • 参与者回答是:
    • COMMIT 请求,等待发生
  • 参与者否:
    • 发送 ABORT 请求

  1. 应用从coodinator拿到一个全局的 txn_id
  2. 带着txn_id发送请求写入数据,开启单节点事务
  3. prepare,机器检查自己状态,可以返回true
  4. 协调者看到任何一家伙不同意就不干了
  5. commit 提交,无限提交

Percolator

PERCOSYS

Google 要爬去网页,总体网页的索引依靠 MapReduce 这样的系统建立,但是具体的增量爬取如果靠 MapReduce 建立索引。Percolator 除了我们要做的事务还提供了 Notify 的功能(不过我们这好像不会用):

原系统对应的 Column 如下:

Percolator_Column

  1. Lock 放的是 锁,可能有 Primary Lock 和一堆 Secondary 的,同时有 PrimaryLock 的位置信息
  2. data: 实际存放数据的地方,不过谁知道呢,可能写的数据丢了没用了,很常见的吧
  3. write: 存放数据的 Bigtable TS,便于你读到以后再来取位置/数据

系统建立的基础是 BigTable/GFS,提供:

  1. Row Transaction (事实上 Percolator 时不时就要用到)
    1. Read/Write
  2. HA

Percolator:

  • Get StartTS
  • Set values
  • Prewrite, 在 startTS 复写 value 并占有 lock, write 啥几把都没有
    • 碰到没有的,写上
    • 读到 lock 说明有并发写入
    • 写到别的,会发生 secondary lock, 指向 primary 的 row, col
  • 同时,读会给出 TS [0, my_tx_start), 读到 lock 会等待,拿到 commit 前的最大的数据
  • 提交时,在primary 上抹掉 startTS 的 lock, 在commitTS 的 write 上写入指向 startTS 的数据
  • 在secondary 上抹掉所有的数据