标签归档:lock

hbase的行锁与多版本并发控制(MVCC)

MVCC (Multiversion Concurrency Control),即多版本并发控制技术,它使得大部分支持行锁的事务引擎,不再单纯的使用行锁来进行数据库的并发控制,取而代之的是,把数据库的行锁与行的多个版本结合起来,只需要很小的开销,就可以实现非锁定读,从而大大提高数据库系统的并发性能。

HBase正是通过行锁+MVCC保证了高效的并发读写。

为什么需要并发控制

HBase系统本身只能保证单行的ACID特性。ACID的含义是:

  • 原子性(Atomicity)
  • 一致性(Consistency)
  • 隔离性(Isolation)
  • 持久性(Durability)

传统的关系型数据库一般都提供了跨越所有数据的ACID特性;为了性能考虑,HBase只提供了基于单行的ACID。

下面是一个hbase并发写的例子。

原始数据如下
mvcc

Apache HBase Write Path一文可以知道hbase写数据是分为两步:
1. 写Write-Ahead-Log(WAL)文件
2. 写MemStore:将每个cell[(row,column)对]的数据写到内存中的memstore

写写同步

假定对写没有采取并发控制,并考虑以下的顺序:

mvcc

最终得到的结果是:

mvcc

这样就得到了不一致的结果。显然我们需要对并发写操作进行同步。
最简单的方式是提供一个基于行的独占锁来保证对同一行写的独立性。所以写的顺序是:

  • (0) 获取行锁
  • (1) 写WAL文件
  • (2) 更新MemStore:将每个cell写入到memstore
  • (3) 释放行锁

读写同步

尽管对并发写加了锁,但是对于读呢?见下面的例子:
mvcc

如果在上面的图中红线所示的地方进行读操作,最终得到的结果是:
mvcc

可见需要对读和写也进行并发控制,不然会得到不一致的数据。最简单的方案就是读和写公用一把锁。这样虽然保证了ACID特性,但是读写操作同时抢占锁会互相影响各自的性能。

MVCC算法

HBase采用了MVCC算法来避免读操作去获取行锁。

对于写操作:

  • (w1) 获取行锁后,每个写操作都立即分配一个写序号
  • (w2) 写操作在保存每个数据cell时都要带上写序号
  • (w3)
--> 阅读全文

基于Redis Lua脚本实现的分布式锁

最近项目中需要用到一个分布式的锁,考虑到基于会话节点实现的zookeeper锁性能不够,于是想使用redis来实现一个分布式的锁。看了网上的几个实现方案后,发现都不够严谨。比如这篇:用Redis实现分布式锁里面设计的锁有个最大的问题是锁的超时值TTL会一直被改写,“尽管C3没拿到锁,但它改写了C4设置的锁的超时值,不过这一点非常微小的误差带来的影响可以忽略不计”,其实在高并发的时候会导致进程“饿死”(也有文章称为死锁)。还有这篇文章“两种分布式锁实现方案2”里面的v2=getset(key,时间戮+超时+1),其加1秒操作在大并发下也会触发同样的问题。网上这篇文章解决了这个“无休止的TTL”问题,我简单翻译了下。


distributedLock

锁是编程中非常常见的概念。在维基百科上对锁有个相当精确的定义:

在计算机科学中,锁是一种在多线程环境中用于强行限制资源访问的同步机制。锁被设计用于执行一个互斥的并发控制策略。

In computer science, a lock is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy.

--> 阅读全文