随笔档案

分布式系统或其它论文里面经常出现下面几个名词：
乐观锁：有时称作optimistic concurrency control, 指并发控制的时候“乐观”地认为冲突的概率很小，万一发生了冲突再重试。具体表现为事务执行过程中不锁住其它事务，等到事务提交的时候看一下是否发生了冲突，如果冲突则重试或回滚，否则提交事务。
悲观锁：并发控制的时候总是很悲观，事务执行过程中锁住其它事务，事务提交时不会有冲突。
从表面上看，悲观锁比较符合计算机基础课上灌输的思维，然而，在分布式系统环境下，异常是常有的事。假设分布式系统采用悲观锁设计，如果客户端发出事务(加锁)请求后异常退出，将导致系统被永久锁住。Web应用存储系统一般采用乐观锁设计，这和Web应用的读/写比例一般超过10相关。系统设计的时候面临这样一种CAS(Compare-And-Swap)需求：如果待操作项符合某个条件则修改。我们可以采用悲观锁锁住待操作项的所有修改，再加上锁的最大持有时间限制，但这样的API设计风险很大，乐观锁可以很好地解决该问题。

coarse-grained vs fine-grained：粗粒度和细粒度。J2EE中常用来指API的粒度，比如, 我有一个远程对象, 他有很多属性和对应的getter和setter方法, 如果我们远程调用对象每个属性的getter和setter方法, 就会产生很多远程方法调用. 这就是fine-grained, 会造成性能问题。所以我们可以用一个setdata或getdata的方法把一些属性的访问封装起来, 只用一个远程方法传输一个data transfer object来对该对象进行赋值和访问, 这就是coarse-grained。Google Chubby中用来表示锁的粒度。coarse-grained指的是分布式锁的持有时间可以很长并不断延长锁的持有时间，这样的好处在于对锁服务器的压力较小，难点在于锁服务端宕机恢复需要恢复锁的状态，find-grained指的是分布式锁的持有时间一般是秒级或者毫秒级，这样的好处在于锁服务器宕机恢复不必维持原有锁的状态，但这种简单的设计方法导致服务器压力很大，不容易扩展到大集群。Google的设计一开始就把集群的线性扩展放到了一个很重要的位置，所以Google Chubby里面使用了coarse-grained的设计。客户端可以简单地在coarse-grained锁的基础上扩展出一个fine-grained的锁，具体请看Chubby论文：scholar.google.cn/scholar