50.javaEE-对接第三方支付(4)-分布式锁

本文的架构如图

一.什么是分布式锁?什么是单体架构锁?

1.什么是单体?集群?分布式?

详情请参照这篇文章:https://blog.csdn.net/qq_26230421/article/details/103409556

2.为什么synchronize和乐观锁等不能在分布式中起作用?

首先我们要明白synchronize和lock等加锁的对象是什么?是对这段代码加锁,那执行这段代码的程序又是那些,是本进程内的所有线程.所以synchronize和lock加锁是指的在同一个服务也就是同一个进程中对所有执行这段代码的线程排序,让它们有序的执行本段代码.而分布式和集群根本执行就不在一台服务器上,更谈不上在一个进程中,所以synchronize和lock加锁对于分布式系统共同操作同一个数据库完全起不到排序的作用.
总之:synchronize和lock是对同一服务器上的同一个进程内的线程排序,不能对分布式或者集群这种不同服务器上的程序排序.

3.什么是分布式锁?

分布式锁其实针对的就不是代码层面上的了,而是针对数据资源,特别是数据库.多个服务共同访问操作数据库,我们需要在特定的情况下,让这些服务排队去做某些操作,例如删除修改等等,这样才能保证数据的一致性.

二.分布式锁实现的策略和方案

其实分布式锁的无外乎就是让所有服务访问同一个数据库资源的时候先排队,和排队的策略就是分布式锁策略.其实分布式锁只需要满足一下几点就完全可以成为一个优秀的分布式解决方案:

• 排队
  排队的意思,就是针对一个资源,如果有人占用了,则其他资源不能使用

  • 数据表的利用业务唯一id插入,插入成功则获取锁成功,否则获取锁失败
  • redis的setnx(业务id)方法,setnx方法成功,代表获取到操作该业务id的锁
  • 例如zookeeper的create节点,创建成功则获取到锁,并且还有监听机制.

• 高可用
  高可用表示这个服务必须是一个集群,或者是服务宕机之后能有备用服务.数据库和redis和zookeeper都满足.

• 如果该解决方案宕机,锁能自动释放
  如果服务宕机是,锁不能自动释放,则导致这个业务永远也操作不了,所以锁自定释放是必须的功能.

  • 数据表,利用java代码中的finally代码块实现锁的释放;
  • redis的setnx方法有超时自动删除key的功能,也能满足
  • zookeeper的临时有序节点,session超时则删除临时节点,也满足

• 队列功能
  队列功能不是必须的,但是是加分项,因为如果一个业务尝试去获取锁,如果获取锁失败了,则放弃加锁的话,则会造成业务的开展缓慢.

  • 数据表,不支持队列的形式.
  • redis也对队列支持不太好
  • zookeeper的watcher监听机制,对队列及加锁比较友好.

(以上优先级由高到低)
请看这篇文章:
https://blog.csdn.net/wuzhiwei549/article/details/80692278