说起分布式的概念，首当其冲就是CAP理论，即满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。但是CAP理论告诉我们，任何系统只能满足其中两个，所以都要求去做取舍。那么人们常说的一般都是，需要牺牲一致性来保证系统的高可用性，只要保证系统的最终一致性，并且允许的时间差值能够被接受就行。对于这个，本人的体会就是订单系统，对于订单系统来说，用户端的一致性需要保证强一致性，但是对于后台或者商家来说的话，这个订单的状态只要保证最终一致性就行，时间差值在可接受范围内就OK。
CAP
一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
分区容错性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP多用于基于分发量大的互联网架设的分布式平台。
两种情况
1.单机的情况下：
单机情况要解决共享资源的访问很容易，Java的API提供了很丰富的解决方案，常见的诸如synchronize，lock，volatile，c.u.t包等等，很多，但是这是在单机情况下，因为只有一个JVM在运行我们的代码。
2.多机的情况下：
这个时候就会出现一套代码出现在多个JVM中，请求落在哪一个上面是随机的。这个时候上面提到的基于Java的API提供的一些解决机制就没法满足要求，它只能解决当前机器中能保证顺序访问共享资源，但是不能保证其他机器。
为了保证一个方法或属性在高并发情况下的同一时间只能被一个服务器上的同一个线程执行。就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。
分布式锁应该具备的特点
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。
分布式锁的三种实现方式
1.基于数据库实现分布式锁；
2.基于缓存（Redis等）实现分布式锁；
3.基于Zookeeper实现分布式锁；
详情参考：https://blog.csdn.net/wuzhiwei549/article/details/80692278