Redis是一個(gè)高性能高效率的key-value存儲(chǔ)的nosql數(shù)據(jù)庫(kù)，由于數(shù)據(jù)是存儲(chǔ)在內(nèi)存中，因此訪問(wèn)速度非常快，由于項(xiàng)目涉及到數(shù)據(jù)庫(kù)的查詢非常多，而數(shù)據(jù)變大并不是非常頻繁，所以在項(xiàng)目中采用Redis分擔(dān)大部分MySQL的壓力。

在項(xiàng)目中實(shí)際使用我用的Redis提供的客戶端連接工具包jedis，在項(xiàng)目中引入jedis.Jar即可。

public static Set<String> searchLike(String like_key) { 
   //線上環(huán)境模糊查詢帶來(lái)嚴(yán)重的性能問(wèn)題，杜絕使用 
   if(!Config.IS_BUG){ 
        return null; 
   } 
   Jedis jedis = RedisApi.getJedis(); 
   boolean is_ok = true; 
   try { 
        if (jedis == null) { 
           return null; 
        } 
        return jedis.keys(like_key); 
    } catch (Exception e) { 
        // TODO: handle exception 
        is_ok = false; 
       return null; 
    } finally { 
        close(jedis, is_ok); 
   } 
} 

每當(dāng)用戶登錄成功之后，都會(huì)生成一個(gè)cookie，分別存在客戶端和Redis數(shù)據(jù)庫(kù)，cookie的key由cookie值+用戶ID組成：cookie字符串+"_"+用戶ID，例如用戶cookie為“d9fb0ea5955fcf0a2183c5076”，用戶ID為 19092,那Redis中存儲(chǔ)的key就是 d9fb0ea5955fcf0a2183c5076_19092,最終的key-vlaue就是： 

{"d9fb0ea5955fcf0a2183c5076_19092":d9fb0ea5955fcf0a2183c5076} 

而在用戶不斷的登錄成功，就不斷地產(chǎn)生這樣的記錄，久而久之，會(huì)積累出非常多的無(wú)用的key，浪費(fèi)redis的空間，也加重了redis查詢的負(fù)擔(dān)，因此想到使用Redis的模糊查詢來(lái)清掉無(wú)用的cookie的key。

而Redis的客戶端jedis操作是通過(guò)jedis.keys(keys)來(lái)完成的，keys可以使用通配符來(lái)匹配Redis中的key。

通配符說(shuō)明：

*: 0到任意多個(gè)字符 eg： searchLike("test*")

?: 1個(gè)字符

比如現(xiàn)在需要清除某個(gè)用戶所有的無(wú)用的cookie的key，，則可以寫(xiě)成“ *_19092 ”。

String key_like = "*_19092"; 
Set<String> keys = RedisApi.searchLike(key_like); 

這樣就可以查出所有這個(gè)用戶的keys，調(diào)用jedis提供的批量刪除key的方法即可達(dá)到目的。

String key_like = "*_19092"; 
Set<String> keys = RedisApi.searchLike(key_like); 

到這里從需求到邏輯到編碼一氣呵成，簡(jiǎn)單測(cè)試沒(méi)什么問(wèn)題后，就發(fā)布到線上，由于平時(shí)網(wǎng)站的流量不算非常高，所以運(yùn)行了幾天也沒(méi)發(fā)生什么異常，直到今天早上，擁有幾十萬(wàn)粉絲的公眾號(hào)發(fā)推文，推文的內(nèi)容直接鏈接到網(wǎng)站，因此說(shuō)瞬間流量是非常高。 

運(yùn)行了大約十分鐘之后，運(yùn)營(yíng)突然發(fā)瘋的過(guò)來(lái)說(shuō)網(wǎng)站訪問(wèn)非常慢，甚至出現(xiàn)錯(cuò)誤碼，心里一慌，趕緊上去看日志，我了個(gè)乖乖啊，簡(jiǎn)直是嚇人，error日志想流水一樣蹦出來(lái)，但五一不例外都是下面圖示的錯(cuò)誤：從Redis池中獲取不大連接數(shù)，馬上上redis服務(wù)器查看，發(fā)現(xiàn)CPU已經(jīng)到達(dá)了100%以上。 

能讓Redis的CPU到100%的，我想出了一下幾個(gè)可能：

1. 連接數(shù)過(guò)多，占用連接的時(shí)間過(guò)長(zhǎng)
2. 存儲(chǔ)的值過(guò)大，存取均很占用CPU和內(nèi)存
3. 慢查詢，事其它操作等待時(shí)間超時(shí)
4. redis阻塞，某個(gè)操作把Redis阻塞，導(dǎo)致CPU飆升

由于項(xiàng)目上線時(shí)間已經(jīng)很久，前三個(gè)可能基本都在平時(shí)查看Redis服務(wù)器性能的過(guò)程中排除掉，因此很大概率是第四個(gè)，突然想起前幾天做的功能，有個(gè)模糊查詢，該不是這個(gè)問(wèn)題吧?我到網(wǎng)站輸入“Redis 模糊查詢 性能”，出來(lái)非常多關(guān)于redis模糊查詢性能急劇下降的的情況，而且建議生產(chǎn)環(huán)境下禁用redis的模糊查詢，于是我把模糊查詢這塊業(yè)務(wù)直接注釋掉，重新上線，運(yùn)行了半天，再?zèng)]出現(xiàn)這個(gè)問(wèn)題，因此可以斷定就是模糊查詢搞的鬼。

【替代方案】

有問(wèn)題肯定是要解決的，既然模糊查詢行不通的，那就得想別的辦法達(dá)到目的，想到Redis有Set這這種存儲(chǔ)結(jié)構(gòu)，因此可以把用戶的所有cookie key都放到一個(gè)用戶專屬的Set中，每次用戶登錄成功之后，都把之前Set里的cookie key清除，然后再把***的key放進(jìn)去，這樣就可以達(dá)到同樣的目的了。 

String setKey = "prefix_customer_cookie_list_10920"; 
       String token="ss2ssssss"; 
        //取出所有的用戶的cookie key 
        Set<String> list = RedisApi.getSet(setKey); 
       if (list != null && list.size() > 0) { 
            //刪除用戶所有的cookie key 
            RedisApi.removeFromSet(setKey, list.toArray(new String[0])); 
        } 
       //把***的cookie key加入到Set中 
        RedisApi.addSet(setKey, token);