为什么Zookeeper天生就是一副分布式锁的胚子？

              .connectString("10.231.128.95:2181,10.231.128.96:2181,10.231.128.97:2181") 

              .retryPolicy(policy) 

              .build(); 

       // 启动客户端 

       client.start(); 

       // 在zookeeper中定义一把锁 

       final InterProcessMutex lock = new InterProcessMutex(client, "/mylock"); 

       //启动是个线程 

       for (int i = 0; i <10; i++) { 

           new Thread(new Runnable() { 

               @Override 

               public void run() { 

                   try { 

                       // 请求得到的锁 

                       lock.acquire(); 

                       printNumber(); 

                  } catch (Exception e) { 

                       e.printStackTrace(); 

                  } finally { 

                       // 释放锁 

                       try { 

                           lock.release(); 

                      } catch (Exception e) { 

                           e.printStackTrace(); 

                      } 

                  } 

              } 

          }).start(); 

      } 

  } 

} 

基于数据的分布式锁

我们在讨论使用分布式锁的时候往往首先排除掉基于数据库的方案，本能的会觉得这个方案不够“高级”。

从性能的角度考虑，基于数据库的方案性能确实不够优异，整体性能对比：缓存>Zookeeper、etcd>数据库。

也有人提出基于数据库的方案问题很多，不太可靠。数据库的方案可能并不适合于频繁写入的操作。

下面我们来了解一下基于数据库(MySQL)的方案，一般分为三类：

基于表记录

乐观锁

悲观锁

基于表记录

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。

当我们想要获得锁的时候，就可以在该表中增加一条记录，想要释放锁的时候就删除这条记录。

为了更好的演示，我们先创建一张数据库表，参考如下：

CREATE TABLE `database_lock` ( 

`id` BIGINT NOT NULL AUTO_INCREMENT, 

`resource` int NOT NULL COMMENT '锁定的资源', 

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!