Java订单系统中并发问题和锁机制的探讨与解决方案二

背景：高并发情况下，商品出现超卖的情况。

最终目标：保证数据的最终一致性。

Contrrler 层框架 ： Spring MVC

第一次尝试： 最初的时候，发现Spring MVC是一个单例多线程的Controller框架。它在多线程同时访问的时候会出现线程不安全的情况。经过分析，发现如果不建立 成员变量 的话，线程不安全的情况是不会出现的。如果需要建立成员变量，解决这个问题可以通过 ThreadLocal 来解决这个问题。 ThreadLocal 可以存储 独属于 线程的变量。（PS：说了这么多还是没解决这个问题）

 

第二次尝试：发现不是Spring MVC的问题后，开始使用 Java1.5新特性中的Lock锁来解决这个问题。保证同一时期，只有一个线程可以进行写的操作。（暂时解决了问题）

第二次尝试失败原因：后续订单量又一步的增长，发现又出现了超卖的情况。细查之后，发现是因为有多个 tomcat 容器，多个tomcat之间的锁不同步导致。

 

第三次尝试：分布式同步锁。在经过大量的资料查询后，分布式锁无法满足 一致性（Consistency）、可用性（Availability）和分区容错性，最多只能满足其中两项。所以，建议各位在程序设计之初就要做出取舍。在互联网这个行业中，我所接触的项目中大多都牺牲了 系统的强一致性 ，从而来换取 系统的可用性（但是系统一定要确保 数据的最终一致性）。为了确保 数据的最终一致性，分布式同步锁就这样诞生了。

目前有一下几种方案：

1，基于缓存实现分布式锁
基于缓存实现的分布式锁，在性能上是非要好的，并且集群部署

使用 setNX 来存储 锁的超时时间戳

语法：

SETNX key value
setNX 解析： 

　　将 key 的值设为 value ，当且仅当 key 不存在。

　　若给定的 key 已经存在，则 SETNX 不做任何动作。

　　SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写

返回值：

　　设置成功，返回 1 。

　　设置失败，返回 0 。

问题一-死锁：如果一个持有锁的客户端失败或崩溃了不能释放锁

问题一-解决方案：可以根据 锁的超时时间戳 来判断是否发生了，如果当前时间大于 lock的值，说明该锁已经失效，可以重新使用。但是要注意，发生这种情况不能 只del 然后 setNX。因为这样的话，当多个线程检测到超时后，就会去 del 该锁，然后持有他。

问题二-多线程持有锁-解决方案：getSET

语法：

GETSET key value
将指定的key设置指定的value值，并且返回之前存储的value值。当没有返回值时，返回 null

假设现在 A1 服务器已经发生了死锁问题。这时 A2 服务器 setNX操作返回0， A2服务器 get操作检查是否超时。如果没超时就继续等待重试。

如果已超时，就通过 getSET 重新设置超时时间，如果 A2服务器拿到的是未超时的值。说明在此之前 A3服务器 先一步进行了 getSET 操作，那么 A2服务器继续等待重试。

注意：当持有锁的 A1 服务器准备 del 的时候，一定要再次检查一下 锁是否超时。如果已超时就不必要解锁了。

 

2，基于Zookeeper实现分布式锁
基于zookeeper临时有序节点可以实现的分布式锁。

注意：基于 Zookeeper 实现的 分布式锁 有效的解决了 死锁这个问题。但是在性能上是不如 缓存锁的，而且需要对Zookeeper的原理有所了解。其次，使用Zookeeper也有可能出现问题。由于网络抖动，客户端与Zookeeper的连接断了，这时Zookeeper就会以为客户端挂了，就会删除锁节点。这时就会产生并发问题。

 

3，基于 数据库实现分布式锁
要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。

当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

 

总结：以上几种方案其实都无法做到完美。

从 实现复杂度来说：Zookeeper与Redis差不多、最为复杂的是数据库

从 性能角度来说：Redis最好、其次Zookeeper、最差为数据库

从 可靠性来说：Zookeeper最好、其次Redis、最差为数据库

个人建议，在使用分布式锁中 不要去使用 数据库的方式来进行操作。操作数据库需要一定的开销，并且行级锁不一定靠谱。