订阅软件研发RSS CSDN首页> 软件研发

[探讨]多版本并发控制(MVCC)在分布式系统中的应用

发表于2012-03-13 09:15| 次阅读| 来源酷壳网| 0 条评论| 作者Todd

摘要:文中探讨了一种基于多版本并发控制(MVCC)思想的Conditional Update解决分布式系统并发控制问题的方法,和基于锁的方法相比,该方法避免了大粒度和长时间的锁定,当各个业务之间资源争用不大的情况下,并发性能很好。

本文来自coolshell网发表的一篇《多版本并发控制(MVCC)在分布式系统中的应用》。文中探讨了一种基于多版本并发控制(MVCC)思想的Conditional Update解决分布式系统并发控制问题的方法,和基于锁的方法相比,该方法避免了大粒度和长时间的锁定,当各个业务之间资源争用不大的情况下,并发性能很好。

问题

最近项目中遇到了一个分布式系统的并发控制问题。该问题可以抽象为:某分布式系统由一个数据中心D和若干业务处理中心L1,L2 … Ln组成;D本质上是一个key-value存储,它对外提供基于HTTP协议的CRUD操作接口。L的业务逻辑可以抽象为下面3个步骤:

  1. read:根据keySet {k1, … kn}从D获取keyValueSet {k1:v1, … kn:vn}
  2. do:根据keyValueSet进行业务处理,得到需要更新的数据集 keyValueSet’{k1′:v1′, … km’:vm’} (:读取的keySet和更新的keySet’可能不同)
  3. update:把keyValueSet’更新到D(:D保证在一次调用更新多个key的原子性)

在没有事务支持的情况下,多个L进行并发处理可能会导致数据一致性问题。比如,考虑 L1 和 L2 的如下执行顺序:

  1. L1从D读取key:123对应的值100
  2. L2从D读取key:123对应的100
  3. L1将key:123更新为100 + 1
  4. L2将key:123更新为100 + 2

如果L1和L2串行执行,key123对应的值将为103,但上面并发执行中L1的执行效果完全被L2所覆盖,实际key 123所对应的值变成了102。

解决方案1:基于锁的事务

为了让L的处理具有可串行化特性(Serializability),一种最直接的解决方案就是考虑为D加上基于锁的简单事务。让L在进行业务处理前先锁定D,完成以后释放锁。另外,为了防止持有锁的L由于某种原因长时间未提交事务,D还需要具有超时机制,当L尝试提交一个已超时的事务时会得到一个错误响应。

本方案的优点是实现简单,缺点是锁定了整个数据集,粒度太大;时间上包含了L的整个处理时间,跨度太长。为此,可以考虑把锁定粒度降低到数据项级别,按key进行锁定,但这又会带来其他的问题。由于更新的keySet’可能是事先不确定的,所以可能无法在开始事务时锁定所有的key;如果分阶段来锁定需要的key,又可能出现死锁(Deadlock)问题。另外,按key锁定在有锁争用的情况下并不能解决锁定时间太长的问题。所以,按Key锁定仍然存在重要的不足之处。

解决方案2:多版本并发控制

为了实现可串行化,同时避免锁机制存在的各种问题,我们可以采用基于多版本并发控制(Multiversion concurrency control,MVCC)思想的无锁事务机制。人们一般把基于锁的并发控制机称成为悲观机制,而把MVCC等机制称为乐观机制。这是因为锁机制是一种预防性的,读会阻塞写,写也会阻塞读,当锁定粒度较大,时间较长是并发性能就不会太好;而MVCC是一种后验性的,读不阻塞写,写也不阻塞读,等到提交的时候才检验是否有冲突,由于没有锁,所以读写不会相互阻塞,从而大大提升了并发性能。目前,Oracle、PostgreSQL和MySQL都已支持基于MVCC的并发机制,但具体实现各有不同。

MVCC的一种简单实现是基于CAS(Compare-and-swap)思想的有条件更新(Conditional Update)。普通的update参数只包含了一个keyValueSet’,Conditional Update在此基础上加上了一组更新条件conditionSet { … data[keyx]=valuex,…},即只有在D满足更新条件的情况下才将数据更新为keyValueSet’;否则,返回错误信息。这样,L就形成了如下图所示的Try/Conditional Update/(Try again)的处理模式:

虽然对单个L来讲不能保证每次都成功更新,但从整个系统来看,总是有任务能够顺利进行。这种方案利用Conditional Update避免了大粒度和长时间的锁定,当各个业务之间资源争用不大的情况下,并发性能很好。不过,由于Conditional Update 需要更多的参数,如果condition 中 value的长度很长,那么每次网络传送的数据量就会比较大,从而导致性能下降。特别是当需要更新的keyValueSet’很小,而 condition 很大时,就显得非常不经济。

为了避免condition太大所带来的性能问题,可以为每条数据项增加一个int型的版本号字段,由D维护该版本号,每次数据有更新就增加版本号;L在进行Conditional Update时,通过版本号取代具体的值。

另一个问题是上面的解决方案假设了D是可以支持Conditional Update的;那么,如果D是一个不支持Conditional Update的第三方的key-value存储怎么办呢?这时,我们可以在L和D之间增加一个P作为代理,所有的CRUD操作都必须经过P,让P来进行条件检查,而实际的数据操作放在D。这种方式实现了条件检查和数据操作的分离,但同时降低了性能,需要在P中增加cache,提升性能。由于P是D的唯一客户端;所以,P的cache管理是非常简单的,不必像多客户端情形担心缓存的失效。不过,实际上,据我所知 redis和Amazon SimpleDB都已经有了Conditional Update的支持。

总结

本文介绍了一种基于多版本并发控制(MVCC)思想的Conditional Update解决分布式系统并发控制问题的方法。和基于锁的方法相比,该方法避免了大粒度和长时间的锁定,当各个业务之间资源争用不大的情况下,并发性能很好。

文章出自:酷壳网

0
0
[探讨]多版本并发控制(MVCC)在分布式系统中的应用
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章