在分布式集群系统的开发中，线程锁每每并不能支持所有场景的使用，必须引入新的技术方案分布式锁。java
线程锁，进程锁，分布式锁
线程锁:你们都不陌生，主要用来给方法、代码块加锁。当某个方法或者代码块使用锁时，那么在同一时刻至多仅有有一个线程在执行该段代码。当有多个线程访问同一对象的加锁方法/代码块时，同一时间只有一个线程在执行，其他线程必需要等待当前线程执行完以后才能执行该代码段。可是，其他线程是能够访问该对象中的非加锁代码块的。redis
进程锁:也是为了控制同一操做系统中多个进程访问一个共享资源，只是由于程序的独立性，各个进程是没法控制其余进程对资源的访问的，可是可使用本地系统的信号量控制（操做系统基本知识）。算法
分布式锁:当多个进程不在同一个系统之中时，使用分布式锁控制多个进程对资源的访问。数据库
原文和做者一块儿讨论:http://www.cnblogs.com/intsmaze/p/6384105.html缓存
分布式锁究竟是什么，怎么实现？tomcat
intsmaze说简单点，实现分布式锁必需要依靠第三方存储介质来存储锁的元数据等信息。好比分布式集群要操做某一行数据时，这个数据的流水号是惟一的，那么咱们就把这个流水号做为一把锁的id，当某进程要操做该数据时，先去第三方存储介质中看该锁id是否存在，若是不存在，则将该锁id写入，而后执对该数据的操做；当其余进程要访问这个数据时，会先到第三方存储介质中查看有没有这个数据的锁id,有的话就认为这行数据目前已经有其余进程在使用了，就会不断地轮询第三方存储介质看其余进程是否释放掉该锁；当进程操做完该数据后，该进程就到第三方存储介质中把该锁id删除掉，这样其余轮询的进程就能获得对该锁的控制。服务器
说了这么多，再补充一点，线程锁，进程锁，分布式锁的做用都是同样的，只是做用的范围大小不一样。范围大小:分布式锁——大于——进程锁——大于——线程锁。能用线程锁，进程锁状况下使用分布式锁也是能够的，能用线程锁的状况下使用进程锁也是能够的。只是范围越大技术复杂度就越大。网络
多年j2EE开发生涯从未感受到分布式锁的痛点!!!
关于分布式锁，有过javaEE开发经验的就会说了，系统为了应对高并发，会搭建一个好比tomcat集群，集群内服务都是访问的同一台数据库，有多台服务器同时修改同一条数据库数据的操做，可是咱们并无在服务器中使用分布式锁？按照上面对分布式锁的解释，两个不一样系统上的JVM进程同时访问数据库的同一个资源，这个时候咱们应该使用分布式锁进行控制。mybatis
这说的没有错，可是咱们忘记了数据库的特性了。若是两台服务器仅仅是直接访问（经过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实现不少功能，好比分布式锁，配置中心。