setnx，是set if not exists的缩写，也就是只有不存在的时候才设置，设置成功时返回1，设置失败时返回0。可以利用它来实现锁的效果，但是很多人在使用的过程中都有一些问题没有考虑到。
例如某个查询数据库的接口因为请求量比较大所以加了缓存，并设定缓存过期后刷新。当并发量比较大并且缓存过期的瞬间，大量并发请求会直接查询数据库导致雪崩。如果使用锁机制来控制只有一个请求去更新缓存就能避免雪崩的问题。下面是很多人下意识想到的加锁方法
$rs = $redis->setnx($key, $value);if ($rs) { //处理更新缓存逻辑 $cache->update(); //删除锁 $redis->del($key);}通过setnx获取锁，如果成功了则更新缓存然后删除锁。其实这里有一个严重的问题：如果更新缓存的时候因为某些原因意外退出了，那么这个锁就不会被删除而一直存在，以至于缓存再也得不到更新。为了解决这个问题有人可能会想到给锁设置一个过期时间，如下
$redis->multi();$redis->setnx($key, $value);$redis->expire($key, $ttl);$redis->exec();因为setNX不具备设置过期时间的功能，所以要借助Expire来设置，同时需要使用Multi/Exec来确保请求的原子性，以免setnx成功了Expire却失败了。这样还有问题：当多个请求到达时，虽然只有一个请求的setnx可以成功，但是任何一个请求的Expire却都可以成功，这就意味着即便获取不到锁也可以刷新过期时间，导致锁一直有效，还是解决不了上面的问题。显然setnx满足不了需求，Redis从2.6.12起，set涵盖了setnx的功能，set本身又包含了设置过期时间的功能，所以使用set就可以解决上面遇到的问题。
$rs = $redis->set($key, $value, array('nx', 'ex' => $ttl));if ($rs) { //处理更新缓存逻辑 // ...... //删除锁 $redis->del($key);}到这一步其实还是有问题的，如果一个请求更新缓存的时间比锁的有效期还要长，导致在缓存更新过程中锁就失效了，此时另一个请求就会获取到锁，但前一个请求在缓存更新完毕的时候，直接删除锁的话就会出现误删其它请求创建的锁的情况。所以要避免这种问题，可以在创建锁的时候需要引入一个随机值并在删除锁的时候加以判断。
$rs = $redis->set($key, $random, array('nx', 'ex' => $ttl));if ($rs) { //处理更新缓存逻辑 // ...... //先判断随机数，是同一个则删除锁 if ($redis->get($key) == $random) { $redis->del($key); }}