1. 程式人生 > >Redis 基礎特性講解

Redis 基礎特性講解

1.Redis基礎雜項小節

1.是什麼

Redis: Remote Dictionary Server(遠端字典伺服器)

是一個高效能的(key/value) 分散式記憶體資料庫,是當前熱門的NoSql資料庫之一

2.能幹嘛

  • 記憶體儲存和持久化
  • 模擬類似於HttpSession這種需要設定過期時間的功能
  • 釋出、訂閱訊息系統 (橫向對比MQ,有一定差距,畢竟不是專門做訊息系統的中介軟體)
  • 定時器、計數器

3.去哪下

redis官網

redis中文網

4.Redis啟動後基礎知識講解

  • 單機版預設16個數據庫,叢集環境該配置不生效,只有一個數據庫,預設Select 0;
  • Dbsize 檢視當前資料庫的key的數量
  • Flushdb 清空當前庫
  • Flushall 通殺全部庫
  • 埠號預設是6379
  • 單程序,單執行緒

2.Redis資料型別

1.常用的五大資料型別

(1). String

String是redis最基本的型別,可以理解成與Memcached一模一樣的型別,一個key對應一個value。

String型別是二進位制安全的。String型別的值最大能儲存512MB

(2). Hash

Redis hash 是一個鍵值(key->value)對集合。

Redis hash 是一個string 型別的 field 和 value的對映表 , hash 特別適合用於儲存物件

(3). List

Redis列表是簡單的字串列表,按照插入順序排序。你可以新增一個元素到列表的頭部(左邊)或者尾部(右邊)。

(4).Set

Redis的Set是string型別的無序集合。它是通過雜湊表來實現的。所以新增,刪除,查詢的複雜度都是O(1)

(5).Zset

Redis Zset和Set 一樣也是string型別元素的集合,且不允許重複的成員。

不同的是每個元素都會關聯一個double型別的分數。redis正是通過分數來為集合中的成員進行從小到大排序的。Zset的成員是唯一的,但分數(score)卻可以重複。

小結

各個資料型別應用場景:

2.高階‘玩家’才知道的其他資料型別

(1).Bitmap

Redis從2.2.0版本開始新增了setbit,getbit,bitcount等幾個bitmap相關命令。雖然是新命令,但是並沒有新增新的資料型別,因為setbit等命令只不過是在set上的擴充套件。在bitmap上可執行AND,OR,XOR以及其它位操作。

(2).HyperLogLog

HyperLogLog 可以接受多個元素作為輸入,並給出輸入元素的基數估算值:

  • 基數:集合中不同元素的數量。比如 {'apple', 'banana', 'cherry', 'banana', 'apple'} 的基數就是 3 。
  • 估算值:演算法給出的基數並不是精確的,可能會比實際稍微多一些或者稍微少一些,但會控制在合

理的範圍之內。

HyperLogLog 的優點是,即使輸入元素的數量或者體積非常非常大,計算基數所需的空間總是固定的、並且是很小的。

每個 HyperLogLog 鍵只需要花費 12 KB 記憶體,就可以計算接近 2^64 個不同元素的基
數。但是,因為 HyperLogLog 只會根據輸入元素來計算基數,而不會儲存輸入元素本身,所以
HyperLogLog 不能像集合那樣,返回輸入的各個元素。

使用HyperLogLog進行資料統計時,需要考慮三要素:

  • 是否需要很少的記憶體去解決問題
  • 是否能容忍一定誤差
  • 是否需要單挑資料

首先,hyperloglog有一定的錯誤率,在使用hyperloglog進行資料統計的過程中,hyperloglog給出的資料不一定是對的
按照維基百科的說法,使用hyperloglog處理10億條資料,佔用1.5Kb記憶體時,錯誤率為2%其次,沒法從hyperloglog中取出單條資料,這很容易理解,使用16KB的記憶體儲存100萬條資料,此時還想把100萬條資料取出來,顯然是不可能的

(3).GEO

GEO即地址資訊定位

可以用來儲存經緯度,計算兩地距離,範圍計算等

(4).PipeLine

流水線功能,允許客戶端可以一次傳送多條命令,而不等待上一條命令執行的結果,主要的核心就是降低了多命令互動時網路通訊的時間。

3.Redis的持久化

1. RDB (Redis DataBase)

(1) 是什麼

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟,它恢復時是將快照檔案直接讀到記憶體裡

Redis會單獨建立(fork)一個子程序來進行持久化,會將資料寫入到一個臨時檔案,待持久化過程都結束了,再用這個臨時檔案替換上次持久化好的檔案。整個過程中,主程序是不進行IO操作的,確保了極高的效能。

如果需要進行大規模資料的恢復,且對於資料恢復的完整性不是非常敏感,那麼RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。

(2) 配置位置 (redis.conf)

RDB 儲存的是 dump.rdb 檔案

(3) 觸發與恢復

觸發:配置、save/bgsave命令、flushall命令
  • 配置檔案預設的快照配置
  • 手動執行 save 或者 bgsave 命令
  • 執行flushall 命令,也會產生dump.rdb檔案,但裡面是空的,無意義

SAVE: save時只管儲存,其他不管,全部阻塞

BGSAVE: redis會在後臺非同步進行快照操作,快照同時可以響應客戶端請求

恢復:將備份檔案 (dump.rdb) 移動到 redis 安裝目錄並啟動服務即可

2. AOF

(1) 是什麼

以日誌的形式來記錄到每個寫操作,將Redis執行過的所有寫指令記錄下來

(2) 配置位置

AOF儲存的是 appendonly.aof檔案

(3). AOF啟動/修復/恢復 以及 Rewrite

正常恢復:

啟動: 設定YES,修改預設的 appendonly no,改為yes

將有資料的 aof 檔案複製一份儲存到對應目錄 (config get dir)

恢復:重啟redis然後重新載入

異常恢復:

啟動:設定YES,修改預設的 appendonly no,改為yes

備份被寫壞的AOF檔案

修復:Redis-check-aof --fix 進行修復

恢復:重啟redis然後重新載入

Rewrite:

是什麼: AOF採用檔案追加的方式,檔案會越來越大為避免出現此種情況,新增了重寫機制,當AOF檔案的大小超過設定的閥值時,Redis就會啟動AOF檔案的內容壓縮,只保留可以恢復資料的最小指令集,可以使用命令bgrewriteaof

重寫機制: AOF檔案持續增長而過大時,會fork出一條新程序來將檔案重寫 (也就是先寫臨時檔案最後再rename),遍歷新程序的記憶體中的資料,每條記錄有一條的Set語句。重寫aof檔案的操作,並沒有讀取舊的aof檔案,而是將整個記憶體中的資料庫內容用命令的方式,重寫了一個新的aof檔案,這點和快照類似

觸發機制: Redis會記錄上次重寫時的AOF大小,預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發

每修改同步:appendfsync always 同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差

每秒同步:appendfsync everysec 非同步操作,每秒記錄 如果一秒內宕機,有資料丟失

不同步:appendfsync no 從不同步

3.總結

  • RDB 持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存

  • AOF持久化方式記錄每次對伺服器寫的操作,當體積過大時會觸發重寫機制

  • 只做快取:當然也可以不使用任何持久化方式

  • 同時開啟兩種持久化的方式:

    在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整.

    RDB的資料不實時,同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢?作者建議不要,因為RDB更適合用於備份資料庫(AOF在不斷變化不好備份),快速重啟,而且不會有AOF可能潛在的bug,留著作為一個萬一的手段。