共计 3018 个字符，预计需要花费 8 分钟才能阅读完成。
任何致力都不能带给你好运，然而它们能让你悄悄地成为更好的本人。
在分布式集群零碎的开发中，线程锁往往并不能反对全副场景的应用，必须引入新的技术计划分布式锁。
线程锁，过程锁，分布式锁
线程锁: 大家都不生疏，次要用来给办法、代码块加锁。当某个办法或者代码块应用锁时，那么在同一时刻至少仅有有一个线程在执行该段代码。当有多个线程拜访同一对象的加锁办法 / 代码块时，同一时间只有一个线程在执行，其余线程必须要期待以后线程执行完之后能力执行该代码段。然而，其余线程是能够拜访该对象中的非加锁代码块的。
过程锁: 也是为了管制同一操作系统中多个过程拜访一个共享资源，只是因为程序的独立性，各个过程是无法控制其余过程对资源的拜访的，然而能够应用本地零碎的信号量管制（操作系统基本知识）。
分布式锁: 当多个过程不在同一个零碎之中时，应用分布式锁管制多个过程对资源的拜访。
分布式锁到底是什么，怎么实现？
intsmaze 说简略点，实现分布式锁必须要依附第三方存储介质来存储锁的元数据等信息。比方分布式集群要操作某一行数据时，这个数据的流水号是惟一的，那么咱们就把这个流水号作为一把锁的 id，当某过程要操作该数据时，先去第三方存储介质中看该锁 id 是否存在，如果不存在，则将该锁 id 写入，而后执对该数据的操作；当其余过程要拜访这个数据时，会先到第三方存储介质中查看有没有这个数据的锁 id, 有的话就认为这行数据目前曾经有其余过程在应用了，就会一直地轮询第三方存储介质看其余过程是否开释掉该锁；当过程操作完该数据后，该过程就到第三方存储介质中把该锁 id 删除掉，这样其余轮询的过程就能失去对该锁的管制。
Redis 中当然不能通过 get,set 操作判断，get,set 操作不是一个原子的，能够应用 redis 的 jedis.set(String key, String value, String nxxx, String expx, int time) 命令来保障原子性。
具体实现计划：https://www.cnblogs.com/linji…
说了这么多，再补充一点，线程锁，过程锁，分布式锁的作用都是一样的，只是作用的范畴大小不同。范畴大小: 分布式锁——大于——过程锁——大于——线程锁。能用线程锁，过程锁状况下应用分布式锁也是能够的，能用线程锁的状况下应用过程锁也是能够的。只是范畴越大技术复杂度就越大。
多年 j2EE 开发生涯从未感觉到分布式锁的痛点!!!
对于分布式锁，有过 javaEE 开发教训的就会说了，零碎为了应答高并发，会搭建一个比方 tomcat 集群，集群内服务都是拜访的同一台数据库，有多台服务器同时批改同一条数据库数据的操作，然而咱们并没有在服务器中应用分布式锁？依照上面对分布式锁的解释，两个不同零碎上的 JVM 过程同时拜访数据库的同一个资源，这个时候咱们应该应用分布式锁进行管制。
这说的没有错，然而咱们遗记了数据库的个性了。如果两台服务器仅仅是间接拜访（通过 url）并操作某台服务器硬盘中某个文件同一行数据，这个时候咱们必须用分布式锁。然而因为这两台服务器拜访的数据是存储在数据库中的（数据库自身就是一个服务程序，多线程的接管内部零碎发来的申请），两台服务器的申请通过网络 IO 发送到数据库服务器后，而后把申请交给数据库服务的过程解决，数据库服务器是多线程接管申请并解决的，这个时候对于某表某一行数据的多线程访问控制是由数据库服务进行管制的（就是数据库服务的代码中进行了线程上的加锁解决），这就是数据库服务器的行锁等个性，因为数据库那一端曾经对外部多个零碎的申请进行了一个锁操作，所以不须要咱们在利用服务端进行分布式锁的开发。
那如果想同时更新数据库的多行数据，这个时候数据库的行锁就无奈保障了。这个时候咱们就要应用分布式锁，是的这个时候就能够应用，留神我用的是能够。为什么说能够呢？因为数据库自身就提供了这个机制，事务以及他的隔离级别。当然你也能够不必数据库提供的事务，用分布式锁。
分布式锁的设计不须要思考业务吗?
分布式锁的设计并不是齐全美妙的，只能针对某些业务场景下应用，如果要对所有业务应用，必须充沛了解业务需要正当的设计，至于起因就和各位 j2ee 开发时 mybatis 的二级缓存以命名空间为单位所要留神的业务问题时一样的。
intsmaze 应用分布式锁，咱们会把某表的第二第三行作为 id 来锁住，如果有雷同的操作时更新该表第二第三行，咱们才不让他批改，必须让他拿到锁才能够。然而如果有个操作仅仅是批改第二行，这个时候他就取得了对该行的操作，而且等数据库开释掉之前操作对该行的锁后。所以分布式锁并不是随处可用的，只是在某些场景下能够应用。比方业务零碎不会存在独自批改第二行的操作。
分布式锁用于 hbase 存储系统
理论开发场景中，咱们会对 hbase 操作进行分布式锁，hbase 作为一款优良的非内存数据库，传统数据库一样提供了事务的概念，只是 HBase 的事务是行级事务，能够保障行级数据的原子性、一致性、隔离性以及持久性，即通常所说的 ACID 个性。为了实现事务个性，HBase 采纳了各种并发控制策略，包含各种锁机制、MVCC 机制等。因为 hbase 只反对行级事物，当业务须要并发操作两行甚至多行记录时，hbase 自身就无奈提供 ACID 的反对了。
数据库拜访量过大除了主从还能如何负载压力？
数据库会为客户端的每一个申请创立一个线程，这些线程针对特定行数据批改必须取得该行的行锁，而其余客户端线程要想批改该数据的话，必须期待后面的线程开释锁后才被容许。如果客户端很多线程都要批改某行数据的话，没有拿到锁的线程都会在数据库端机器上一直轮询，增大数据库端的压力。
咱们能够应用分布式锁，把对数据库行锁的期待获取的轮询放到每一个客户端机器下来实现，这样能够防止数据库端线程的一直轮询。比方，客户端在要发送对数据库的某行数据的操作申请前，在客户端机器上进行锁的争抢，没有获取到锁，就不会像数据库端发送操作申请，这样数据库端就没有了轮询的压力。当然分布式锁的引入肯定要联合业务的需要来进行设计，不然会呈现锁 id 的命名不全导致读取的数据不统一，数据过期生效等问题。
应用那种第三方介质寄存分布式锁?
目前风行的是 zookeeper 和 redis，两者各有益处，redis 风行的内存缓存，且能进行程度扩容同时还能进步申请负载，面对高并分布式锁数据的读写申请能高速响应，同时有 aof, 哨兵机制能够避免某台宕机分布式锁数据失落带来的问题。
zookeeper 我是比拟喜爱，因为他是分布式一致性算法 paxos 算法的实现，面对高负载申请毫无压力，同时某一台宕机毫不影响分布式锁数据一致性，且附带了监听机制，当某一程序开释某一个锁后，其余程序能够及时失去告诉来取得对该分布式锁的控制权，这里的轮询实现不须要咱们去开发了。
对于分布式锁与线程锁的介绍从一年前就在编辑中，始终没有工夫以一种艰深明了的形式介绍给大家。自己在很多论坛中发现很多刚入大数据畛域的新人都会提到分布式锁，然而并没有粗浅明确分布式锁和线程锁的场景，以至于很多状况下明明线程锁就能够搞定的却引入了分布式锁，让整个零碎设计的更加简单了。
另外要说的，zookeeper 笔者认为是很棒的技术，尽管在大数据畛域只是作为某一个框架的一个协调者呈现，导致很多开发者漠视了他的平凡性。然而我想说的，在以后炽热的微服务中，其实会借助 zookeeper 实现很多性能，比方分布式锁，配置核心。
