一、通過setnx實現
1、setnx key value
當且僅當key不存在，將key的值設定為value，並且返回1；若是給定的key已經存在，則setnx不做任何動作，返回0。

public static Boolean setnx(final String key, final String value, final long seconds) {
        return getShardedJedisClient().execute(new ShardedJedisAction<Boolean>() {
            public Boolean doAction
 
(ShardedJedis shardedJedis) {
                Jedis jedis = (Jedis) shardedJedis.getShard(key);
                String result = jedis.set(key, value, "NX", "EX", seconds);
                return "OK".equalsIgnoreCase(result);
            }
        });
    }

2、get key
獲取key對應的value值，如果不存在該key，返回0。

public
 
 String get(final String key) {
        this.checkIsInMulti();
        return (String)this.execute(new SmartJedis.Action<String>() {
            public String doAction(Jedis jedis) {
                return jedis.get(key);
            }
        }, SmartJedis.RW.R, key);
    }

3、getset key value

public static String getset(final String key, final String value) {
        return getShardedJedisClient().execute(new ShardedJedisAction<String>() {
            @Override
            public String doAction(ShardedJedis shardedJedis) {
                return shardedJedis.getSet(key, value);
            }
        });
    }

至此，我們先舉個手機三要素驗證的列子：(A渠道系統，業務B系統，外部廠商C系統)
(1)B業務系統呼叫A渠道系統，驗證傳入的手機、身份證、號碼三要素是否一一致。
(2)A渠道系統再呼叫外部廠商C系統。
(3)A渠道系統將結果返回給B業務系統。
這3個過程中，(2)過程，外部廠商的呼叫時是需要計費的。
當B業務系統併發量很高時，有100筆相同的三要素校驗，由於是相同的三要素，A渠道只要呼叫一次廠商即可知道結果。那麼A渠道系統如何控制不讓100筆請求全部去訪問外部廠商C系統呢？
小明提出了方案一：
在A系統中，
當100個執行緒同時請求過來，進行redis.setnx(“LOCK_KEY_phone&idNo&name”,”demo”)，這樣第一筆執行緒率先拿到鎖，其他的執行緒等待，當thread(0)處理結束後，thread(0)進行delete(“LOCK_KEY_phone&idNo&name”),把鎖放開，thread(i)進行get(“LOCK_KEY_phone&idNo&name”)拿到0，說明上一筆已經處理完成，這個時候，我們可以去查詢上一筆的記錄。

RedisUtils.setnx("LOCK_KEY_phone&idNo&name","demo");
JSONObject result = A.request(B);
AssetUtils.notNull(result,ResponseCodeEnum.Success,"拿到結果");
ResultDmo resultDmo = (ResultDmo)BeanUtils.maptoBean(result);
resultDao.insert(resultDmo);
if(result!=0){
  //上一筆同樣的請求還未處理完成，輪訓等待(具體如何輪訓在此不展開)
}else{
  //上一筆同樣的請求處理完成，進行查庫操作
  resultDao.select("引數");
}

小巨集說：小明的思想不嚴謹
問題：當100筆執行緒中一些執行緒超時或者系統宕機等意外情況發現，鎖會一直被某些執行緒持有，造成死鎖狀態。
應該給快取key設定一個超時時間。比如:200ms

RedisUtils.setnx("LOCK_KEY_phone&idNo&name","demo",200);

這種情況是，大致判斷了外部廠商C系統業務處理時間大概為200ms，

==============================================================================================================================
網上看還有一種方式（B）：

RedisUtils.setnx("LOCK_KEY_phone&idNo&name",currentTime,200);
Long old = RedisUtils.get("LOCK_KEY_phone&idNo&name");
Long new = System.currentTimeMillis();
Long time = new - old;
if(time>0){
//處理已經超時
RedisUtils.delete("LOCK_KEY_phone&idNo&name");
}

（B）這種情況不嚴謹：當a獲取setnx鎖，a執行緒崩潰或超時，b、c執行緒同時get到old，且判斷超時，可能出現b執行緒delete a執行緒的鎖，並且setnx後；c執行緒又將b執行緒的鎖delete,並且setnx。這種情況完全鎖不住執行緒了。

（B）方案的升級版—->>（C）方案：

當a獲取setnx鎖，a執行緒崩潰或超時，b執行緒getset，獲取old且判斷超時，c執行緒getset，獲取old（此時這個值是b剛剛set進去的），判斷未超時，c繼續等待。b執行緒delete a執行緒的鎖，並且setnx後。這種情況是安全的。

需要注意的地方：
①不要輕易將get和getset混用，筆者認為getset單獨使用比較好。
有一種情況，a、b、c、三個執行緒，a、b同時get，a立即返回了old，突然來了個c，卡在b之前getset了，且刪除鎖，那麼b的get只能返回nil了。此時再根據時間戳對比：
a.get != (a.set)
b.get ! = (b.set)
這樣a、b都沒拿到鎖，但是a其實已經獲取到了鎖。
②多個伺服器時間的同步問題。

總結： 鎖超時了該如何處理，通過getset方式判斷時間戳差的方式，多比同時getset都得到超時，同時去setnx。總會有一個更快地去setnx。

===============================================================================================================================

二、通過incr搶佔資源實現
1、incr
將 key 中儲存的數字值增一。如果 key 不存在，那麼 key 的值會先被初始化為 0 ，然後再執行 INCR 操作。如果值包含錯誤的型別，或字串型別的值不能表示為數字，那麼返回一個錯誤。

public static Long incr(final String key) {
        return shardedClient.execute(new ShardedJedisAction<Long>() {
            @Override
            public Long doAction(ShardedJedis shardedJedis) {
                shardedJedis.expire(key, 200);
                return shardedJedis.incr(key);
            }
        });
    }

還是上面的三要素的例子

Long result = RedisUtils.incr("LOCK_KEY_phone&idNo&name");
        if (result > 1) {
            //如果計數器>1,說明已經有請求進來
            throw new AppException(ResponseCode.FAIL.getCode(), "操作頻繁");
        }
=========================================================================================================================================

 Long startTime = System.currentTimeMillis();
 JSONObject result = A.request(B);
 Long endTime = System.currentTimeMillis();
 Long time = endTime - startTime;
  //如果處理時間大於incr的key存活時間,說明該筆請求已經超時
  if (time > 200) {
      //全域性ID,統計超時次數
      String key = "LOCK_KEY_phone&idNo&name" + source;
      RedisUtils.incr(key);
      int total = Integer.valueOf(RedisUtils.get(key));
      //斷言若超時10次,進行報警(報警不在次展開)
      AssertUtils.isTrue(total < 10, ResponseCode.FAIL, "呼叫" + source + "渠道超時");
  }

這裡設定了計數器的超時時間為200ms，如果請求超時，會有大量的執行緒同時訪問，筆者這裡有10筆同時過來，就啟動報警。人為排查渠道。和setnx的不同是，某個執行緒超時，setnx的方式需要手動去判斷，再去加鎖，防止大量執行緒進入(這裡可以通過輪訓實現)；而incr的方式超時了，大量執行緒進來，我不做處理，但是這裡的time>200是具有誤差的。