在分布式集群系统的开发中，线程锁往往不能支持所有场景的使用，必须引入新的技术方案分布式锁。
线程锁，进程锁，分布式锁
线程锁定：人人都很熟悉，但主要用于锁定方法、代码块。 如果方法或代码块使用锁定，则每次最多只能有一个线程在运行该代码。 如果多个线程访问同一对象的锁定方法/代码块，则必须在同一时间只运行一个线程，而其余的线程必须在当前线程执行完成之前运行代码段。 但是，其余的线程可以访问该对象中未锁定的代码块。进程锁定：还用于控制同一操作系统中的多个进程访问一个共享资源。 但是，由于程序的独立性，每个进程不能控制其他进程对资源的访问，但是可以使用本地系统的信号控制(操作系统的基础)。
分布式锁定：如果多个进程不在同一系统中，则使用分布式锁定来控制对多个进程的资源的访问。
分布式锁到底是什么，怎么实现？
intsmaze简单地说，要实现分布式锁定，必须依赖第三方存储介质来存储锁定的元数据等信息。 例如，当尝试操作分布式集群所在行的数据时，该数据流的编号是唯一的。 如果，则以该流号码为密钥id，当某个进程要操作该数据时，首先去看该密钥id是否存在于第三方的存储介质中，如果不存在，则写入该密钥id，然后执行对该数据的操作； 当其他进程尝试访问此数据时，它首先会检查第三方存储介质中是否有此数据的锁定id。 如果有，则认为此数据当前正被其他进程使用，并不断轮询其他进程是否已解除锁定。 当进程处理数据时，该进程会在第三方存储介质上删除锁定id，以便其他轮询进程可以控制锁定。Redis当然不能通过get、set操作进行判断。 get，set操作不是原子，而是使用Redis的jedis.set (字符串密钥、字符串值、字符串nxxx、字符串expx、整数时间)命令
我只说了这么多，再加一个，线程锁、进程锁、分布式锁的作用相同，但作用范围的大小不同。 范围大小：分布式锁定——大于——进程锁定——大于——线程锁定。 可以使用线程锁，在进程锁的情况下可以使用分布式锁，在线程锁可以使用的情况下也可以使用进程锁。 只是，范围越大，技术上就越复杂。
关于
多年j2EE开发生涯从未感觉到分布式锁的痛点!!!
分散锁定，有开发javaEE经验的人说。 系统为了应对高并发性，例如构建tomcat集群。 集群内的服务都是访问的同一数据库，多个服务器同时进行修改同一数据库数据的操作，但是我们在服务器上没有使用分布式锁吗？ 如上所述，如果两个不同系统上的JVM进程同时访问数据库中的相同资源，则必须使用分布式锁定进行控制。这是毫无疑问的，但我忘记了数据库的特性。 如果两台服务器只通过“url”直接访问，并且只需要处理一台服务器的硬盘上文件中同一行的数据，则必须使用分布式锁定。 但是，由于这两台服务器访问的数据存储在数据库中，(数据库本身是服务程序，多线程接收来自外部系统的请求)，所以两台服务器的请求通过网络I ) o 数据库服务器由多线程接收请求进行处理。 此时，对某个表中某行数据的多线程访问控制由数据库服务控制。 也就是说，数据库服务的代码正在执行线程上的锁定。 这就是数据库服务的行锁定等特性。 由于数据库端已经对外部多个系统的请求进行了锁定操作，所以不需要在APP服务端开发分布式锁定。
如果尝试同时更新数据库中的多个行数据，此时将无法保证数据库中的行锁定。 这个时候，我们使用分散锁。 是的，这个时候可以使用。 请注意我用的很好。 为什么说好呢？ 因为数据库本身提供了这个机制、事务和他的隔离级别。 当然，也可以使用分布式锁定，而不用数据库提供的事务。
分布式锁的设计不需要考虑业务吗？
分布式锁的设计并不完全美观，只能用于特定的业务场景。 要用于所有业务，必须充分理解业务需求的合理设计。 其原因与j2ee开发时mybatis的l2缓存在命名空间单位中需要注意的业务问题相同。intsmaze使用的是分布式锁定。 我们把某张桌子的第2、3行作为id进行锁定。 如果有同样的操作时更新了那个表格的第2、3行，我们就不会让他修改。 必须让他取得锁定。 但是，如果只进行修改第二行的操作，他就会检索对该行的操作，然后在释放数据库之前解除对该行的锁定。 因此，分布式锁不是随处可用的，它只是在某些场景下可用。 例如，业务系统中不存在单独修改第2行的操作。
分布式锁用于hbase存储系统
在实际的开发场景中，针对hba se操作进行分布式锁，hbase作为一款优秀的非内存数据库，传统数据库一样提供了事务的概念，只是HBase的事务是行级事务，可以保证行级数据的原子性、一致性、隔离性以及持久性，即通常所说的ACID特性。为了实现事务特性，HBase采用了各种并发控制策略，包括各种锁机制、MVCC机制等。因为hbase只支持行级事物，当业务需要并发操作两行甚至多行记录时，hbase本身就无法提供ACID的支持了。数据库访问量过大除了主从还能如何负载压力？
数据库会为客户端的每一个请求创建一个线程，这些线程针对特定行数据修改必须获得该行的行锁，而其他客户端线程要想修改该数据的话，必须等待前面的线程释放锁后才被允许。如果客户端很多线程都要修改某行数据的话，没有拿到锁的线程都会在数据库端机器上不断轮询，增大数据库端的压力。
我们可以使用分布式锁，把对数据库行锁的等待获取的轮询放到每一个客户端机器上去实现，这样可以避免数据库端线程的不断轮询。比如，客户端在要发送对数据库的某行数据的操作请求前，在客户端机器上进行锁的争抢，没有获取到锁，就不会像数据库端发送操作请求，这样数据库端就没有了轮询的压力。当然分布式锁的引入一定要结合业务的需求来进行设计，不然会出现锁id的命名不全导致读取的数据不一致，数据过期失效等问题。
使用那种第三方介质存放分布式锁?
目前流行的是zookeeper和redis，两者各有好处，redis流行的内存缓存，且能进行水平扩容同时还能提高请求负载，面对高并分布式锁数据的读写请求能高速响应，同时有aof,现代的枫叶机制可以防止某台宕机分布式锁数据丢失带来的问题。
zookeeper我是比较喜欢，因为他是分布式一致性算法paxos算法的实现，面对高负载请求毫无压力，同时某一台宕机毫不影响分布式锁数据一致性，且附带了监听机制，当某一程序释放某一个锁后，其他程序可以及时得到通知来获得对该分布式锁的控制权，这里的轮询实现不需要我们去开发了。
关于分布式锁与线程锁的介绍从一年前就在编辑中，一直没有时间以一种通俗明了的方式介绍给大家。本人在很多论坛中发现很多刚入大数据领域的新人都会提到分布式锁，但是并没有深刻明白分布式锁和线程锁的场景，以至于很多情况下明明线程锁就可以搞定的却引入了分布式锁，让整个系统设计的更加复杂了。
另外要说的，zookeeper笔者认为是很棒的技术，虽然在大数据领域只是作为某一个框架的一个协调者出现，导致很多开发者忽视了他的伟大性。但是我想说的，在当前火热的微服务中，其实会借助zookeeper实现很多功能，比如分布式锁，配置中心。