关于分布式锁

可以考虑自己写一个。

Java 语言里有个 ReentrantLock 就支持重入 。Redis 分布式锁如果要支持可重入，可对客户端的 set 方法进行包装，使用线程的 Threadlocal 变量存储当前持有锁的计数。不过，调整业务代码完全可以避免重入锁，没必要的

一般情况下使用 redLock 就行了，对一致性要求非常高的情况下就用 etcd，但是自己还是要做幂等的。

@mmdsun 考虑了好久怎么写，突然想到好像莫得作用。。。谢谢指导

分布式锁在加一条吧：
一定要有 lease 机制，否则中间要是宕机了就永远都释放不了了。进程内锁一般不会有这个问题

不同的服务 业务上肯定是解耦的，一般不存在还要获取同一个锁的问题。分布式锁大部分的应用场景，是相同的业务，在不同机器的 JVM 上执行，操作相同的 redis 和 DB，此时需要保证同时只有一台机器执行。

接好： https://github.com/redisson/redisson/wiki/8.-%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E5%92%8C%E5%90%8C%E6%AD%A5%E5%99%A8

应该满足你所有对锁的要求

推荐用 redis 来实现乐观锁的分布式锁
1.满足分布式需求，redis 作为单独进程可共享数据，内部单线程，保证操作数据安全
2.首先根据你下面说的问题我就很奇怪了，无论是 synchronized 还是 ReentrantLock 都只是允许同一线程可冲入，可是他们都不满足分布式需求，可重入完全可以从代码层面解决，key 为同一的名字，value 则可以 ip+threadId，其他线程取值发现有值并且不同则等待，相同则可冲入，还可以根据 value 做一些保证数据一致性操作，幂等性等等
3.这个需求本身就有问题，如果服务器宕机，如果是代码层面的早就不复存在了，redis 本身提供 TTL 即时持有锁的线程宕机，也可以在 TTL 到期自动删除解锁