In conventional single service, how to ensure the same time there is only one thread operating a code block, the easiest way to use the synchronized keyword, and jdk own lock, but how in distributed projects inside the program can not apply , and is present in the synchronized jvm is, when there are multiple instances less suitable, and this time the program distributed on the introduction of the lock.
Distributed Lock realization of the program based on common but how redis and distributed based on how the zoo project which guarantee the same time only one thread operating inside a code block, the easiest way to use the synchronized keyword, and the jdk that comes with lock, the program can not be applied, the synchronized is present in the jvm, when there are multiple instances less suitable, and this time the program distributed on the introduction of the lock.
Distributed Lock common realization of the program and based on redis zookeeper
redis is a single-process architecture, based on setnx instruction multiple threads simultaneously access codes, who performed setnx successful, the lock is successful, then execute the business after completion, release the lock, but when if an exception occurs during the execution of the program, and in jvm process if suddenly hang up, then, are likely to result in a deadlock situation, based on the performance of distributed lock also has some influence redis implemented multiple threads competing locking is operating by different spin to see if I can lock No success.
zookeeper implementation of distributed lock is achieved by temporarily node, a good solution to redis distributed lock problem, zookeeper receive command creates a temporary node, the master node does not succeed immediately returned to the client, but first create own log file commands stored in the temporary node, as well as from the log file nodes, before returning to the client is successful, the program is locked successfully, zookeeper there is a listening watch mechanism, multiple threads listening root, by callback mechanism, as long as no less than its own node, you can lock success, a good solution to constantly spin performance issues
