redis 分布式锁不适合高并发情况，如何优化？
努力不一定成功,但是不努力一定很轻松。
既然是锁，就一定存在竞争，那redis在某些情况下不适合高并发，如何优化
分布式锁竞争
当多个客户端同时获取redis锁时，锁争用频繁发生，此时的性能会严重下降。为了解决这个问题，可以采用两种方式
- 延长等待锁的时间
如果一个客户端当前获取不到锁，可以通过设置一个循环去重试获取锁的机制，并设置一个较长时间的锁等待时间，这个时间需要看应用场景设置。这种方式可以在将锁释放时利用Lua脚本的原子性保证锁的准确释放。
- 引入随机数
在进行锁争用时，为每个客户端分配一个由随机数和本地进程标识符组成的客户端序号。在客户端申请锁之前，先设置排队标识符，这个标识符由客户端序号和入队时间戳组成。如果一个客户端申请锁的时候发现正位于队列末尾，那么它的申请必须经过足够的时间，以确保在它之前的所有客户端的锁都已被释放。这种方式可以有效降低锁的抢占。
redis 连接处和锁的释放
在进行锁设计的时候，需要保证所有的Redis连接池只被初始化一次，尽量减少Redis连接池的连接数目。另外，在释放锁时，需要保证线程持有的连接和锁是同一个节点的，否则可能会导致锁释放失败。
Redis服务节点的故障
当一个Redis节点故障之后，应该把这个节点从Redis分布式锁中移除。当某个客户端在一个失效的Redis节点上获得锁，这将导致死锁。我们可以设置一个心跳检测机制，检测Redis分布式锁中所有的Redis服务节点是否都是可用的状态。如果一个服务不可用，则将这个服务从服务列表里移除即可。这里可以采用zookeeper等其他分布式协调服务来基于服务的订阅、发布机制进行处理。
