Redis的正確使用姿勢

深夜裡的程式猿發表於2019-04-02

前言

說到分散式快取,可能大多數人腦海浮現的就是redis了,為什麼redis能夠在競爭激烈的快取大戰中脫穎而出呢?原因無非有一下幾點:效能好,豐富的特性跟資料結構,api操作簡單。但是用的人多了,就會出現很多不規範或者疏忽的地方,嚴重的時候甚至會導致生產事故,所以我們有必要來聊聊在Redis使用過程中的一些“正確姿勢“。

切忌裸奔

大家別笑... 很多初學者或者沒經驗的開發人員在伺服器上用root使用者裝了redis以後,開啟預設埠直接就愉快的執行起來了,開放了外網及預設埠的連線,甚至對於生產環境也這樣,貪圖一時的方便,這種情況比較多的出現在一些初創公司 (包括N年前的我也這麼幹過...)

那麼會出現什麼問題呢?最常見的就是Redis未授權訪問漏洞。攻擊者掃描到網際網路開放的ip以及預設的6379埠後,直接在本地遠端連線你伺服器的redis,通過redis的命令將本機生成的公鑰寫入到伺服器的authorized.keys中,這時候本機就可以ssh免密登入進來了。接下來可以寫入反彈shell,提權,然後就可以為所欲為了,這就是為什麼你的伺服器上面會突然出現有挖礦程式的一個原因。

為了防止出現上述的風險,我們可以從以下幾個地方來處理。

  • 修改預設埠6379

  • 繫結內網訪問 bing 127.0.0.1

  • 新增redis的密碼驗證

  • 以低許可權的使用者執行redis

  • 必要時設定防火牆策略

禁止“ key *” ,用“scan”代替

說到這個,筆者也是滿滿的淚,在年少無知的時候曾經在生產環境執行過這個命令,後來差點收拾揹包提前下班了。為什麼這個操作這麼可怕呢?“key *” 操作的意思是返回資料庫中所有匹配的key,它會掃一次性掃描所有的記錄,當你庫裡的資料量很大的時候,會造成redis的阻塞,cpu使用率飆升,慢慢的拖垮專案中對redis的相關請求直至出現各種timeout...

在Redis2.8版本以後,提供了一個更好的遍歷key的操作"scan",它類似於我們jdbc中ResultSet,通過一個遊標來迭代。使用方法為“SCAN cursor [MATCH pattern] [COUNT count]”。

redis 127.0.0.1:6379> scan 0
1) "17"
2)  1) "key:12"
    2) "key:8"
    3) "key:4"
    4) "key:14"
    5) "key:16"
    6) "key:17"
    7) "key:15"
    8) "key:10"
    9) "key:3"
    10) "key:7"
    11) "key:1"

redis 127.0.0.1:6379> scan 17
1) "0"
2) 1) "key:5"
   2) "key:18"
   3) "key:0"
   4) "key:2"
   5) "key:19"
   6) "key:13"
   7) "key:6"
   8) "key:9"
   9) "key:11"
複製程式碼

“scan 0 ”表示開始一個新的迭代,當返回的第一引數為0時,則表示迭代結束,若不為0,下一次迭代的時候帶上這個遊標開始下一次遍歷,直到返回0.第二個引數則是當前遍歷出來的值。使用的時候需要注意版本,當版本低於2.8時,需升級才能使用。

key的設計

首先用“:”來分割key是一個約定俗成的東西,自己使用的時候就儘量不要用一些比較特殊的字元來代替。關於我們的key設計可以參照我們的關係型資料庫。

假如有一個user表,有userid,age,username欄位,那麼我們key就可以"user:userid:useridValue:username"這麼來設計,把表名作為key的字首,查詢的條件放在最後。中間用欄位跟它所對應的value分割開來,所有的設計都是為了在查詢的時候可以更便捷。

合理使用多個db

redis的db下標預設0-15,也就是有16個。通常大部分人都是使用db0,所有的k-v都在一個庫中。這其實沒多大問題,但是redis不是關係型資料庫,儲存的資料相互耦合不那麼大,所以建議可以按照不同的業務把資料分散到各個庫中,這樣我們可以select 不同的 db 來執行不同的業務模組操作。

善用5種資料結構

redis提供了5種資料結構,但是根據以往的面試結果來看,很多應聘者幾乎在專案中只用到string型別,甚至對其他型別一知半解。其實當我們能在不同的場景善用不同的結構的話,效率會有很大的提升。下面簡單介紹幾個例子。

SortSet

它提供了一個優先順序(score)來排序,我們可以把score的值設定成時間戳,這樣我們可以通過一些定時的操作來取出某段時間裡面資料,在我們專案的機器人模組中有大量的此類操作。還有常用的地方是排行榜,通過score值的變化來快速高效的更新榜單。

list

它的實現是一個雙向連結串列,我們可以把一些需要執行的任務通過lpush,rpush存放進來,組成符合我們需求的順序,最後我們在依次取出來執行,類似於mq。

set

用來做一些自動去重的操作,比如redis的交集命令,可以取出2個人的共同好友。

禁用高危命令

redis中有很多高危命令。如“flushdb”,“config”等,我們可以禁止或者重新命名這些命令來使得操作更加安全。

我們需要修改redis的配置檔案redis.conf,在SECURITY這一項中,新增

   rename-command FLUSHALL ""

   rename-command CONFIG ""
複製程式碼

假如是重新命名的話

   rename-command FLUSHALL abcdefg
複製程式碼

配置完重啟後生效。

結語

對於redis的話題,其實還有很多,比如釋出訂閱,持久化機制,叢集等。很多最佳實踐都需要結合自身的業務不斷摸索,還是那句話,適合自己的才是最好的。

Redis的正確使用姿勢

喜歡的話,關注一下公眾號《深夜裡的程式猿》,每天更新高質量IT文章~

相關文章