Redis的模糊查詢(xún)?cè)谏a(chǎn)環(huán)境出現(xiàn)嚴(yán)重的性能問(wèn)題
Redis是一個(gè)高性能高效率的key-value存儲(chǔ)的nosql數(shù)據(jù)庫(kù)，由于數(shù)據(jù)是存儲(chǔ)在內(nèi)存中，因此訪問(wèn)速度非常快，由于項(xiàng)目涉及到數(shù)據(jù)庫(kù)的查詢(xún)非常多，而數(shù)據(jù)變大并不是非常頻繁，所以在項(xiàng)目中采用Redis分擔(dān)大部分MySQL的壓力。
在項(xiàng)目中實(shí)際使用我用的Redis提供的客戶(hù)端連接工具包jedis，在項(xiàng)目中引入jedis.Jar即可。
- public static Set<String> searchLike(String like_key) {
- //線上環(huán)境模糊查詢(xú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)用戶(hù)登錄成功之后，都會(huì)生成一個(gè)cookie，分別存在客戶(hù)端和Redis數(shù)據(jù)庫(kù)，cookie的key由cookie值+用戶(hù)ID組成：cookie字符串+"_"+用戶(hù)ID，例如用戶(hù)cookie為“d9fb0ea5955fcf0a2183c5076”，用戶(hù)ID為 19092,那Redis中存儲(chǔ)的key就是 d9fb0ea5955fcf0a2183c5076_19092,最終的key-vlaue就是：
- {"d9fb0ea5955fcf0a2183c5076_19092":d9fb0ea5955fcf0a2183c5076}
而在用戶(hù)不斷的登錄成功，就不斷地產(chǎn)生這樣的記錄，久而久之，會(huì)積累出非常多的無(wú)用的key，浪費(fèi)redis的空間，也加重了redis查詢(xún)的負(fù)擔(dān)，因此想到使用Redis的模糊查詢(xún)來(lái)清掉無(wú)用的cookie的key。
而Redis的客戶(hù)端jedis操作是通過(guò)jedis.keys(keys)來(lái)完成的，keys可以使用通配符來(lái)匹配Redis中的key。
通配符說(shuō)明：
*: 0到任意多個(gè)字符 eg： searchLike("test*")
?: 1個(gè)字符
比如現(xiàn)在需要清除某個(gè)用戶(hù)所有的無(wú)用的cookie的key，，則可以寫(xiě)成“ *_19092 ”。
- String key_like = "*_19092";
- Set<String> keys = RedisApi.searchLike(key_like);
這樣就可以查出所有這個(gè)用戶(hù)的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è)可能：
- 連接數(shù)過(guò)多，占用連接的時(shí)間過(guò)長(zhǎng)
- 存儲(chǔ)的值過(guò)大，存取均很占用CPU和內(nèi)存
- 慢查詢(xún)，事其它操作等待時(shí)間超時(shí)
- redis阻塞，某個(gè)操作把Redis阻塞，導(dǎo)致CPU飆升
由于項(xiàng)目上線時(shí)間已經(jīng)很久，前三個(gè)可能基本都在平時(shí)查看Redis服務(wù)器性能的過(guò)程中排除掉，因此很大概率是第四個(gè)，突然想起前幾天做的功能，有個(gè)模糊查詢(xún)，該不是這個(gè)問(wèn)題吧?我到網(wǎng)站輸入“Redis 模糊查詢(xún) 性能”，出來(lái)非常多關(guān)于redis模糊查詢(xún)性能急劇下降的的情況，而且建議生產(chǎn)環(huán)境下禁用redis的模糊查詢(xún)，于是我把模糊查詢(xún)這塊業(yè)務(wù)直接注釋掉，重新上線，運(yùn)行了半天，再?zèng)]出現(xiàn)這個(gè)問(wèn)題，因此可以斷定就是模糊查詢(xún)搞的鬼。
【替代方案】
有問(wèn)題肯定是要解決的，既然模糊查詢(xún)行不通的，那就得想別的辦法達(dá)到目的，想到Redis有Set這這種存儲(chǔ)結(jié)構(gòu)，因此可以把用戶(hù)的所有cookie key都放到一個(gè)用戶(hù)專(zhuān)屬的Set中，每次用戶(hù)登錄成功之后，都把之前Set里的cookie key清除，然后再把***的key放進(jìn)去，這樣就可以達(dá)到同樣的目的了。
- String setKey = "prefix_customer_cookie_list_10920";
- String token="ss2ssssss";
- //取出所有的用戶(hù)的cookie key
- Set<String> list = RedisApi.getSet(setKey);
- if (list != null && list.size() > 0) {
- //刪除用戶(hù)所有的cookie key
- RedisApi.removeFromSet(setKey, list.toArray(new String[0]));
- }
- //把***的cookie key加入到Set中
- RedisApi.addSet(setKey, token);
