Distributed trend
Currently almost many large sites and applications are deployed in a distributed, distributed scenario we will encounter a very important issue: data consistency. As distributed CAP theory said the same: "Any of a distributed system can not meet at the same time consistency (Consistency), availability (Availability) and partitions fault tolerance (Partition tolerance), we can only meet two." So, many of these three systems will be trade-offs early in the design. In most of the scenes in the Internet field, we need to sacrifice strong consistency in exchange for high availability, systems often only need to ensure that "eventual consistency", as long as this is the final time to the user within the acceptable range.
In many scenarios, we have to ensure that the final data consistency requires a lot of technical solutions to support, such as distributed transactions, distributed lock, timed task scheduling. Although Java provides a number of parallel processing API, but the API in a distributed scenario becomes helpless.
So for the implementation of distributed locks we need to use other tools, the current commonly used are the following options:
- Based on implementation of distributed database lock
- Based caching (redis, memcached, tair) implement a distributed lock
- Based achieve Zookeeper distributed lock
Benpian issued under our main say Redis-based distributed lock combat.
Before actually writing code, we say that under the first condition
Distributed Lock four conditions are available:
- Mutually exclusive. At any time, only one client can hold the lock.
- A deadlock does not occur. Even with a client during a crash without holding the lock to unlock the initiative, but also to ensure follow-up to other clients can lock.
- Fault tolerant. As long as most of the Redis functioning node, the client can lock and unlock.
- The trouble should end it. Locking and unlocking must be the same client, the client's own people can not be added to the solution of the lock.
Distributed Lock practical steps:
Write ILock Interface
Write ILock interface
LockGetter abstract class
We can see from the illustration, a specific locking the success or failure of specific business go through LockGetter abstract class. This is a thought to keep in mind the students in mind. Able to skillfully use it, he will make you go more smoothly in the programming of the road.
此外，可以看到，我们实际加锁就一行代码：jedis.set(fieldKey, value, "NX", "EX", seconds);，这个set()方法一共有五个形参：
第一个参数为key，我们使用key来当锁，因为key是唯一的。
第二个参数为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个参数为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个参数为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个参数为time，与第四个参数相呼应，代表key的过期时间。
总的来说，执行上面的set()方法之后会出现两种情况：
- 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。
- 锁已经存在，redis不做任何操作。
总结：
使用缓存来实现分布式锁优点：
- 可以提供更好的性能，同时很多缓存服务都是集群部署的，可以避免单点问题。
- 很多缓存服务都提供了可以用来实现分布式锁的方法，比如redis的setnx方法等。
- 缓存服务也都提供了对数据的过期自动删除的支持，可以直接设置超时时间来控制锁的释放。
使用缓存实现分布式锁尽管性能好，实现起来较为方便。但也不是没有缺点，有时候我们的程序内部出现异常后可能会发生死锁，这就需要开发时候注意代码编写，后续测试人员测试时候测试案例要尽可能覆盖。
