论分布式系统中单一锁控制的优化

前言

---

在分布式系统中，为了保持数据操作的一致性，我们会看到锁在里面会有广泛的应用。简单一点的，我们可能就用一个简单的对象锁来做线程安全的同步。再细粒度一些的，我们会用到读写锁，然后对具体操作的属性（Read Or Write）在进行读写锁的分离控制。但今天笔者想对此话题再展开细致的探讨，相比较于使用单一锁模式，我们还是可以做出更进一步的改善的。

单一锁控制的弊端

---

如前文所提到的，不管说是普通的object对象锁还是说ReadWriteLock来说，它们本质上还是Single Lock（单一锁）。这种lock在客户端请求巨大的情况下会有严重的锁竞争问题，一个典型的例子是HDFS NN里的FSN锁。一旦某个请求获得了这个锁，那么其它的请求就会被block住了。所以说单一锁的问题在于，它的粒度有些时候还是太粗了。所以这里就涉及到一个锁粒度的问题了。

单一锁的优化：锁粒度的细化

---

那么怎么取做锁粒度的细化呢？读写锁的分离是一种常见的手段。但更好的一种做法是在实际资源上进行锁控制。因为我们使用锁去做线程安全同步控制时的初衷，是为了避免同时又多个操作在修改某个共同的资源（比如元数据的更新）。但其实不同的资源的相互更新其实是不影响的，那这时我们可以将大的锁拆分为A资源锁以及B资源锁。

用一个更具象的例子来解释这个问题：比如在分布式存储系统的元数据更新里，我们可以将DB级别的lock控制拆分为以table级别的lock。这里的Resource就从DB细粒度为Table。

锁的管理

---

如果锁的粒度已经按照对于实际的资源进行控制的话，这时我们可以考虑在上面包装出一个锁的管理器，由此管理器对外“借出”或“归还”锁。在这个管理类里，我们还能对当前的活跃锁做引用计数的更新。如果某个锁在某次unlock后没有再被外部引用了，我们就可以将其从锁管理器中移除出去了。

锁的容量控制

---

当然我们还需要对锁管理器做一个最大容量的控制，如果当前活跃锁达到容量阈值时，则后面的新锁申请也将会被Block住。这在一定程度上控制的是客户端的concurrency的行为度。

锁的资源优先级问题

---

这里还有一个隐蔽的问题：锁的资源优先级问题。比如说我们有3个资源，它们的资源范围关系如下：

• A，资源最大(包含多个B类资源）
• B，资源适中（包含多个C类资源）
• C，最小粒度资源

假设我们对上述3类资源做锁控制的话，可以遵循以下原则：

在持有低优先级资源锁的情况下，不能继续再获取其上资源的锁。持有高优先级资源锁的情况下，还可以继续获取其下低一级资源的锁。

这个原则对应上面ABC资源的情况就是，用户在获取A锁资源的情况下，可以继续获取B或C资源的锁，而假如说目前已经获取C锁的情况下，是无法获取B锁和A锁的。

锁管理的demo样例

---

以下是摘自Hadoop Ozone里的一个锁管理器的实现，里面涉及到了上文提到的一些要点，供大家学习参考。

/**
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with this
 * work for additional information regarding copyright ownership.  The ASF
 * licenses this file to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * <p>
 * http://www.apache.org/licenses/LICENSE-2.0
 * <p>
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * License for the specific language governing permissions and limitations under
 * the License.
 */

package org.apache.hadoop.ozone.lock;

import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.hdds.HddsConfigKeys;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

/**
 * Manages the locks on a given resource. A new lock is created for each
 * and every unique resource. Uniqueness of resource de