Redis 基礎特性講解

丁可樂發表於2019-05-28
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
  • 單程式，單執行緒

Redis 基礎特性講解

2.Redis資料型別

1.常用的五大資料型別

(1). String

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

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

Redis 基礎特性講解

(2). Hash

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

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

Redis 基礎特性講解

(3). List

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

Redis 基礎特性講解

(4).Set

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

Redis 基礎特性講解

(5).Zset

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

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

Redis 基礎特性講解

小結

各個資料型別應用場景:

Redis 基礎特性講解

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即地址資訊定位

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

Redis 基礎特性講解

(4).PipeLine

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

3.Redis的持久化

1. RDB (Redis DataBase)

(1) 是什麼

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

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

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

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

Redis 基礎特性講解

RDB 儲存的是 dump.rdb 檔案

(3) 觸發與恢復

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

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

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

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

2. AOF

(1) 是什麼

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

(2) 配置位置

Redis 基礎特性講解

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，留著作為一個萬一的手段。

相關文章