#この記事の動作環境: Windows システム、redis 6.0、thinkpad t480 コンピューター。分散ロックを実装する 3 つの方法: 1. データベースに基づいて分散ロックを実装する; 2. キャッシュに基づいて分散ロックを実装する (Redis など); 3. Zookeeper に基づいて分散ロックを実装する。パフォーマンスの観点から見ると (高から低の順): 「キャッシュ モード > Zookeeper モード > = データベース モード」。
分散ロックを実装する 3 つの方法:
1. データベースに基づいて分散ロックを実装する;2. キャッシュに基づいて分散ロックを実装する (Redis など) ) ;
3. Zookeeper に基づいて分散ロックを実装する;
1. データベースに基づいて分散ロックを実装する
#1. 悲観的ロック更新排他ロックには select...where... を使用します注: その他の追加機能は基本的に実装と同じです。ここで注意する必要があるのは、「where name=lock」です。 "、名前フィールドにインデックスを付ける必要があります。そうでない場合、テーブルはロックされます。テーブルが大きくない場合など、場合によっては、MySQL オプティマイザがこのインデックスを使用しないため、テーブル ロックの問題が発生します。 2. オプティミスティック ロックいわゆるオプティミスティック ロックと以前のロックの最大の違いは、それが CAS の考え方に基づいていることです。相互に排他的ではなく、ロックを引き起こしません。待機してリソースを消費し、操作中は存在しないと見なされます。同時実行性の競合は、更新バージョンが失敗した後にのみ検出できます。ラッシュセールとフラッシュセールは、過剰販売を防ぐためにこの実装を使用しています。 インクリメンタル バージョン番号フィールドを追加して、オプティミスティック ロックを実装します。
次に、キャッシュ (Redis など) に基づいた分散ロックを実装します。
1. コマンドの使用方法の概要:(1) SETNX
SETNX key val: キーが存在しない場合に限り、key val で文字列を設定し、1 を返します。 ; if キーが存在する場合は何もせず、0 を返します。
(2)expire
expire key timeout: キーのタイムアウトを設定します (単位は秒)。この時間が経過すると、デッドロックを回避するためにロックが自動的に解放されます。
(3) delete
delete key: delete key
(1) ロックを取得するとき、setnx を使用してロックをロックし、expired コマンドを使用してロックにタイムアウト期間を追加します。ロックの値 ロックを解除する際の判断に使用される、ランダムに生成されるUUIDです。
(2) ロックを取得する際には、取得のタイムアウト時間を設定し、この時間を超えるとロックの取得を諦めます。
(3) ロックを解除する場合は、UUIDでロックかどうかを判断し、ロックの場合はdeleteを実行してロックを解除します。
/** * 分布式锁的简单实现代码 */ public class DistributedLock { private final JedisPool jedisPool; public DistributedLock(JedisPool jedisPool) { this.jedisPool = jedisPool; } /** * 加锁 * @param lockName 锁的key * @param acquireTimeout 获取超时时间 * @param timeout 锁的超时时间 * @return 锁标识 */ public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) { Jedis conn = null; String retIdentifier = null; try { // 获取连接 conn = jedisPool.getResource(); // 随机生成一个value String identifier = UUID.randomUUID().toString(); // 锁名,即key值 String lockKey = "lock:" + lockName; // 超时时间,上锁后超过此时间则自动释放锁 int lockExpire = (int) (timeout / ); // 获取锁的超时时间,超过这个时间则放弃获取锁 long end = System.currentTimeMillis() + acquireTimeout; while (System.currentTimeMillis() results = transaction.exec(); if (results == null) { continue; } retFlag = true; } conn.unwatch(); break; } } catch (JedisException e) { e.printStackTrace(); } finally { if (conn != null) { conn.close(); } } return retFlag; } }4. 実装したばかりの分散ロックをテストしますこの例では、50 個のスレッドを使用してフラッシュ セールをシミュレートしています。プロダクトの場合、-演算子を使用して商品を削減し、結果の順序からロックされているかどうかを確認できます。 フラッシュ セール サービスをシミュレートし、その中で jedis スレッド プールを構成し、それを使用するための初期化中に分散ロックに渡します。
public class Service { private static JedisPool pool = null; private DistributedLock lock = new DistributedLock(pool); int n = 500; static { JedisPoolConfig config = new JedisPoolConfig(); // 设置最大连接数 config.setMaxTotal(200); // 设置最大空闲数 config.setMaxIdle(8); // 设置最大等待时间 config.setMaxWaitMillis(1000 * 100); // 在borrow一个jedis实例时,是否需要验证,若为true,则所有jedis实例均是可用的 config.setTestOnBorrow(true); pool = new JedisPool(config, "127.0.0.1", 6379, 3000); } public void seckill() { // 返回锁的value值,供释放锁时候进行判断 String identifier = lock.lockWithTimeout("resource", 5000, 1000); System.out.println(Thread.currentThread().getName() + "获得了锁"); System.out.println(--n); lock.releaseLock("resource", identifier); } }Flash Kill サービスのスレッドをシミュレートします;
public class ThreadA extends Thread { private Service service; public ThreadA(Service service) { this.service = service; } @Override public void run() { service.seckill(); } } public class Test { public static void main(String[] args) { Service service = new Service(); for (int i = 0; i 結果は次のとおりです (結果の順序は次のとおりです):<p></p><p><img src="https://img.php.cn/upload/article/000/000/024/0c1cb2ceea4c8cbfa184228a02822f99-1.png" alt="分散ロックの 3 つの実装方法は何ですか?"></p>コメントする場合ロックの使用を排除する部分: <p></p><pre class="brush:php;toolbar:false">public void seckill() { // 返回锁的value值,供释放锁时候进行判断 //String indentifier = lock.lockWithTimeout("resource", 5000, 1000); System.out.println(Thread.currentThread().getName() + "获得了锁"); System.out.println(--n); //lock.releaseLock("resource", indentifier); }結果からわかるように、一部は非同期で実行されます:
3、 Zookeeper Lock に基づいて配布#ZooKeeper は、分散アプリケーションに一貫したサービスを提供するオープン ソース コンポーネントです。内部的には、階層的なファイル システムのディレクトリ ツリー構造であり、存在できるのは 1 つだけであることが規定されています同じディレクトリ内にある一意のファイル名。 ZooKeeper に基づいて分散ロックを実装する手順は次のとおりです:
(1) ディレクトリ mylock を作成します;
(2) スレッド A は、mylock ディレクトリに一時シーケンス ノードを作成します。 lock; (3 ) mylock ディレクトリ内のすべての子ノードを取得し、それよりも小さい兄弟ノードを取得します。存在しない場合は、現在のスレッドのシーケンス番号が最小であることを意味し、ロックが取得されます。 ;
(4) スレッド B はすべてのノードを取得し、それが最小のノードではないと判断し、自分より小さいノードを監視するように設定します;
(5) スレッド A の処理が終了したら、自身のノードを削除します。 B は変更イベントをリッスンし、それが最小ノードであるかどうかを判断し、最小ノードである場合はロックを取得します。
ここでは、ZooKeeper クライアントである Apache オープン ソース ライブラリである Curator を推奨します。Curator が提供する InterProcessMutex は分散ロックの実装です。ロックの取得には取得メソッドが使用され、解放メソッドは使用されます。ロックを解除します。
実装ソース コードは次のとおりです。
import lombok.extern.slf4j.Slf4j; import org.apache.commons.lang.StringUtils; import org.apache.curator.framework.CuratorFramework; import org.apache.curator.framework.CuratorFrameworkFactory; import org.apache.curator.retry.RetryNTimes; import org.apache.zookeeper.CreateMode; import org.apache.zookeeper.data.Stat; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.stereotype.Component; /** * 分布式锁Zookeeper实现 * */ @Slf4j @Component public class ZkLock implements DistributionLock { private String zkAddress = "zk_adress"; private static final String root = "package root"; private CuratorFramework zkClient; private final String LOCK_PREFIX = "/lock_"; @Bean public DistributionLock initZkLock() { if (StringUtils.isBlank(root)) { throw new RuntimeException("zookeeper 'root' can't be null"); } zkClient = CuratorFrameworkFactory .builder() .connectString(zkAddress) .retryPolicy(new RetryNTimes(2000, 20000)) .namespace(root) .build(); zkClient.start(); return this; } public boolean tryLock(String lockName) { lockName = LOCK_PREFIX+lockName; boolean locked = true; try { Stat stat = zkClient.checkExists().forPath(lockName); if (stat == null) { log.info("tryLock:{}", lockName); stat = zkClient.checkExists().forPath(lockName); if (stat == null) { zkClient .create() .creatingParentsIfNeeded() .withMode(CreateMode.EPHEMERAL) .forPath(lockName, "1".getBytes()); } else { log.warn("double-check stat.version:{}", stat.getAversion()); locked = false; } } else { log.warn("check stat.version:{}", stat.getAversion()); locked = false; } } catch (Exception e) { locked = false; } return locked; } public boolean tryLock(String key, long timeout) { return false; } public void release(String lockName) { lockName = LOCK_PREFIX+lockName; try { zkClient .delete() .guaranteed() .deletingChildrenIfNeeded() .forPath(lockName); log.info("release:{}", lockName); } catch (Exception e) { log.error("删除", e); } } public void setZkAddress(String zkAddress) { this.zkAddress = zkAddress; } }
利点: 高可用性、再入性、ブロック ロックの特性があり、障害によるデッドロックの問題を解決できます。
欠点: ノードを頻繁に作成および削除する必要があるため、パフォーマンスは Redis 方式ほど良くありません。
4、比較
データベース分散ロックの実装欠点:
1. DB 操作のパフォーマンスが悪く、テーブル ロックのリスクがある
2. ノンブロッキング操作が失敗した後はポーリングが必要となり、CPU リソースを占有します;
3. コミットがありません長時間または長時間のポーリングは、より多くの接続リソースを占有する可能性があります
Redis (キャッシュ) 分散ロックの実装
欠点:
1. の有効期限ロック削除の失敗を制御するのは難しい
2. ノンブロッキング、操作が失敗した後はポーリングが必要となり、CPU リソースが占有されます;
ZK 分散ロックの実装
欠点: パフォーマンスは Redis 実装ほど良くありません。主な理由は、書き込みのすべての操作 (ロックの取得とロックの解放) をリーダー上で実行し、その後フォロワーに同期する必要があることです。
要約: ZooKeeper は優れたパフォーマンスと信頼性を備えています。
理解しやすさの観点から (低位から高位の順) データベース > キャッシュ > Zookeeper
実装の複雑さの観点から (低位から高位の順) Zookeeper >= キャッシュ > ; データベース
パフォーマンスの観点から (高から低の順) キャッシュ> Zookeeper >= データベース
信頼性の観点から (高から低の順) Zookeeper > キャッシュ> データベース
関連する推奨事項: 「プログラミング教育」
以上が分散ロックの 3 つの実装方法は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。