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