问：你们使用什么分布式锁
答：我们使用了redission的分布式锁。具体做法是后端接收到请求后加入一个分布式锁，如果加锁成功，就执行业务，如果加锁失败就等待锁或者拒绝请求。业务执行完成后释放锁。redission底层是使用的setnx命令来获取锁的。
问：如果业务还没有执行完成，但是redis锁过期了，怎么办？
答：当客户端加锁成功后，redission会启动一个定时任务，每隔1/3时间来检测业务是否处理完成，检测的依据就是判断分布式锁的key是否还存在，如果存在，就进行续约。
问：如果客户端宕机了，这时分布式锁还可以续期吗?
答：因为分布式锁的续期是在客户端执行的，所以如果客户端宕机了，续期线程就不能工作了，也就不能续期了。这时等到分布式锁到了超时时间就会自动删除。
问：你使用分布式锁过程中有没有出现分布式锁失效的情况？
答：有的。在事务内部使用锁，锁在事务提交前释放，数据库出现重复数据。应该在事务外层使用锁。
问：Redis分布式锁，master 挂了但slave 没有完成复制，锁失效了，导致第二个客户端获取了锁，这种情况遇到过吗？
答：没有。
问：redis分布式锁在极端情况下不一定是安全的，如果对并发安全零容忍，为了保证正确性怎么办？
答：可以做一些兜底措施，如果一段业务不希望重复执行，可以做成幂等操作，比如业务号在数据库是唯一索引，这样重复执行就会失败不会影响结果。如果希望锁失效后，还能重新尝试获取锁并执行补偿逻辑，确保最终一致性，可以在锁获取失败时候，将补偿消息发送到kafka中，消费者监听kafka，重新获取锁，进行补偿逻辑执行。
