分布式锁

[b]1、使用场景[/b]
在分布式y应用服务集群中，有时处理一个定时任务必须在某一时刻只有一个线程执行，而其他线程必须等待。
可以举一个真实的例子，需要具体怎么样处理？
1）两个交易中心处理订单时需要保证另一个无法处理；
[b]2、设计方案及思路[/b]
[b]1)阻塞模式[/b]
如果需要阻塞可以通过while循环处理，具体操作需要详细说明

[b]2)失效时间[/b]
主要防止在解锁过程中出现超时或者服务宕机，导致无法解锁；如果设置失效时间那么即使在服务宕机后也可以解锁成功；

但失效时间设置多少比较合理？
1）如果设置时间太短，可能线程处理业务时间比较长或者有阻塞，那么就会导致第二个线程持有该锁产生线程安全问题；
2）如果设置时间太长，导致在分布式锁服务宕机，其他线程需要等待过多的时间，使整体服务性能下降包括处理时间及tps；

如何解决这种问题比较关键？
1）先自己设定方案
假定锁服务设置锁的超时时间为3s，当线程处理业务超过2s还没有释放锁，则就把超时时间延长至原来的一倍（6s），依此类推但必须设置上限假设设置60s为上限，达到60s就会自动删除锁；
1】那么问题如何精确定位时间是否达到2s，并重新设置超时时间，如果线程在执行一个任务时出现阻塞时，就一直持有锁，如果出现这种情况又如何处理？
通过另一个锁服务线程检查该锁是否达到2s；如果该获取锁的线程阻塞，那么达到60s后将锁至为失效，如果使用的是redis锁服务那么使用redis定期删除过期数据（在立即删除与定时删除的中间方案）

[b]3、是否可重入[/b]

[b]4)如果同时有多个线程竞争锁是否需要加入队列，是否可实现公平与非公平竞争[/b]
[b]3、优势与不足[/b]

以上内容均为研究中的一些总结及想法，同时也会有些不足和缺陷，以后的实践过程中会不断改正。仅此参考。
参考：
http://ifeve.com/redis-lock/
http://www.weizijun.cn/2016/03/17/%E8%81%8A%E4%B8%80%E8%81%8A%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E7%9A%84%E8%AE%BE%E8%AE%A1/