Lecture#18 Multi-Version Concurrency Control

Posted Angelia-Wang

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Lecture#18 Multi-Version Concurrency Control相关的知识,希望对你有一定的参考价值。

MVCC 不是并发控制的 (继 2PL、时间戳控制协议) 第三种实现,它不单独作为一种并发控制的实现,而是与 2PL / 时间戳控制协议 (T/O、OCC) 结合使用。

多版本并发控制 (MVCC) 首次被提出是在 1978 年的一篇 MIT 的博士论文中。在 80 年代早期,DEC 的 Rdb/VMS 和 InterBase 首次真正实现了 MVCC,其作者是 Jim Starkey,NuoDB 的联合创始人。如今,Rdb/VMS 成了 Oracle Rdb,InterBase 成为开源项目 Firebird。

1 Multi-Version Concurrency Control

简言之,实现 MVCC 的 DBMS 在内部维持着单个逻辑数据的多个物理版本:

  • 当事务修改某数据时,DBMS 将为其创建一个新的版本;
  • 当事务读取某数据时,它将读到该数据在事务开始时刻之前的最新版本。

MVCC 的核心优势可以总结为以下两句话:

  • Writers don\'t block readers. 写不阻塞读
  • Readers don\'t block writers. 读不阻塞写

只读事务无需加锁就可以读取数据库某一时刻的快照 (使用时间戳来决定版本),如果保留数据的所有历史版本,DBMS 甚至能够支持读取任意历史版本的数据,即 time-travel queries。

[9][lecture] Lecture 5: Raft

6.824 2017 Lecture 5: Raft (1)

第一部分,介绍raft选举和log复制技术,相关的lab是lab2A 2B;第二部分设计,raft持久化,client行为以及快照技术,涉及lab 2C和lab 3

  • 目前为止,讨论的技术主要是使用RSM技术做容错,比如configure server,gfs master或者mapreduce主节点,要达到的效果就是复制集对于client的表现和单点server一致,且具备容错性,挂少数的server依旧可用,策略就是复制,复制log同样的顺序执行,gfs和vmft都是这个套路
  • 如何避免脑裂?集群分裂为AB,client连接到A,那么B挂了,A一定要可用;B没挂,那么要么A可用要么B可用,不能都可用
  • 主要问题是无法区别crash或者网络不可达
  • 我们需要RSM具备以下特性:第一,少数挂掉依旧可用;第二,处理网络分区问题避免脑裂;第三,多数挂掉,修复后依旧可用
  • 多数投票制度可以避免分区,防止脑裂,1990s主要技术就是paxos和view-timestamped replication技术,两者都在工业系统中得到实践;raft提出的比较晚

raft overview

lab 3 system,multi-clients,3 replicas,k/v layer,raft layer,logs

  • server’s raft layer选主
  • client发送rpc请求到主节点,put,get,append
  • k/v layer将请求转发到raft layer,此时不返回client,raft复制log到复制集节点,多数完成复制后,主节点commit,确保这个command已经持久化且达到了一致性要求,此时server apply这个command到到k/v state machine,其他节点通过心跳得到commit信息,本地执行,主节点在commit之后返回到KV layer,KV layer执行命令到db,返回给client
  • 为何选取log技术?命令单身不够吗,要加入term信息,index信息,保证复制集之间达成一致,同时做写前日志使用,未完成commit时,持久化供后续commit

lab 2A 选主

leader简化了复制过程;raft中使用term代表逻辑时间序列,每个term一个主或者没有主,不会有2个主;每次选举有一个唯一的term,term帮助区分哪些节点比较新

  • 发起选举的时机?followers timeout没收到心跳信息,发起选举;候选者 timeout发起新一轮选举
  • 成为候选人后的具体操作?首先,获取多数票,成为leader,本地统计投票(对拜占庭问题无法解决);然后,对于没有得到多数票的场景,如果其他选主成功,成功追随者;如果没有选出主来,等待timeout继续下一轮选举,选举过程中要保证主节点日志最新,保证了不丢失数据
  • 如何保证只有一个主?多数票决定,且每个term每个节点只能一次投票
  • 成为新主后的操作?发送心跳,防止下一轮选举发生
  • 选举失败可能的原因?没有足够的节点,分票
  • 选举失败后面?继续选,直到成功为止
  • 如何设计超时时间?随机超时设计,防止分票,不能太大防止长时间无主,不能太小,会造成分票选举失败;最少需要几倍的rpc执行时间,允许几次重试

lab 2B log复制

区别replicated log vs commited log,提交的log保证永远不会丢失,复制的但是没提交的log可能被覆盖。

  • commit机制保证了,server只会执行稳定的log entry,即commit过的,commit过的意味着在当前term保证了多数节点复制成功
  • leader无法复制上一任期的log entry,如果它没有commit,依旧会丢失
  • 主节点覆盖log的时机?log务必是没有提交过的;过世的log会被主节点发来的消息覆盖掉

接口rf.Start(command) (index, term, isleader)

  • kv service中put和get请求执行start,来就一个log entry达成共识,start立即返回,此时kv应等待commit返回的isLeader告诉是否要请求其他节点,term帮助确认当前主节点是否过期,index帮助确定是否已提交

接口ApplyMsg, with Index and Command

  • Raft发送消息到applychannel,对于每条commit过的entry,此时等待的kv会开始真正执行command

raft FAQ

Q: raft为了简单牺牲了什么?

A: 主要牺牲了性能;比如每个op需要单独落盘保证一致性,如果可以batch会提升性能;第二,appendentry只能从主到从,且in-order,out-order就需要反复重试,可以流水线最好;第三,快照机制对于小的状态可以,对于大的状态不可用;第四,恢复回放对于大的状态也比较慢,完整的发送快照;第五,多核利用性不好,每次只能执行一个操作按照in log order TODO why;上述都可以通过修改基本协议来改进

Q: paxos?

A: paxos基本协议解决的问题是多个角色就一个值达成一致,因此需要额外的补充实现,持久化等等,已经基于paxos实践的系统,chubby,zookeeper,paxos made live,具体的实现都很复杂,不容易理解。raft容易理解,但是要实际使用还需要一些改进,来达到理想的性能。paxos 1980s,raft 2012,raft和view timestamp类似,后者在1988s提出。基于raft的系统变得多了起来,包括etcd,tikv,rethinkDB,CockroachDB等等

Q: raft性能如何?

A: paxos变种zab很快,不过最新的改进版本raft在etcd3中显示已经优化的更快了

Q: 少数节点存在下,是否可以保证可用性?

A: 取决于一致性要求,raft是强一致性的系统,因此不行。如果放宽一致性要求,可以实现,比如最终一致性。主要解决的问题是脑裂,主要方案有两种。第一,明确少数节点活着,多数节点挂掉了,需要人为介入,因为机器无法区别挂了还是网络中断了;第二,允许双写,稍后来处理冲突,一些nosql场景下可以大幅度提高性能,保障最终一致性。

Q: 选举过程中服务是halt住的?

A: 是的,不过实际中选举很短,发生频率也很低,影响较小

Q: 是否介意不通过选举完成一致性?

A: 可以,paxos就是如此,但是需要更多的通信达成共识

Q: raft vs vmft

A: vmft更广泛,raft只能对那些基于此协议的软件生效,但是raft会更加高效

Q: fake 消息?

A: 一般来说,raft相信节点都是可靠度的,可以部署在内网环境;如果要公网部署,则可以每个节点配置公私钥对,加密所有rpc请求完成认证操作。

Q: 如何使用raft接口?

A: 比如lab3,get put请求首先调用Start,然后读applychann得知是否commit,完成后续操作返回client

Q: 超时时间设置多少合适?

A: 太短,还没选举完成就超时了,频繁超时有负担;太长,浪费了不可用时间

Q: 主节点不挂也会切主吗?

A: 可能的,网络分区也会导致切主

Q: 主节点发送rpc后应该阻塞等待吗?

A: 绝不,发起新的go完成发送,同时原子更新返回的个数,达到多数时可以commit

reference

以上是关于Lecture#18 Multi-Version Concurrency Control的主要内容,如果未能解决你的问题,请参考以下文章

TiKV 的 MVCC(Multi-Version Concurrency Control)机制

Abstract Harmonic Analysis Lecture Notes

2017.7.17-2017.7.23

[10][lecture] Lecture 6: Raft

[10][lecture] Lecture 6: Raft

[4][lecture] Lecture 3: GFS