小米面试题：讲一下Redis分布式锁

为什么需要分布式锁？

在我们的日常开发中，一个进程中当多线程的去竞争某一资源的时候，我们通常会用一把锁来保证只有一个线程获取到资源。如加上synchronize关键字或ReentrantLock锁等操作。

那么，如果是多个进程相互竞争一个资源，如何保证资源只会被一个操作者持有呢？

例如：微服务的架构下，多个应用服务要同时对同一条数据做修改，那么要确保数据的正确性，就只能有一个应用修改成功。

server1、server2、server3 这三个服务都要修改amount这个数据，每个服务更新的值不同，为了保证数据的正确性，三个服务都向lock server服务申请修改权限，最终server2拿到了修改权限，即server2将amount更新为2，其他服务由于没有获取到修改权限则返回更新失败。

基于redis实现分布式锁

为什么redis可以实现分布式锁？

因为redis是一个单独的非业务服务，不会受到其他业务服务的限制，所有的业务服务都可以向redis发送写入命令，且只有一个业务服务可以写入命令成功，那么这个写入命令成功的服务即获得了锁，可以进行后续对资源的操作，其他未写入成功的服务，则进行其他处理。

如何实现？

redis的String类型就可以实现。

锁的获取

setnx命令：表示SET if Not eXists，即如果 key 不存在，才会设置它的值，否则什么也不做。

两个客户端同时向redis写入try_lock，客户端1写入成功，即获取分布式锁成功。客户端2写入失败，则获取分布式锁失败。

锁的释放

当客户端1操作完后，释放锁资源，即删除try_lock。那么此时客户端2再次尝试获取锁时，则会获取锁成功。