Redis 基礎特性講解

目錄

• 1.Redis基礎雜項小節
  • 1.是什麼
  • 2.能幹嗎
  • 3.去哪下
  • 4.Redis啓動後基礎知識講解
• 2.Redis數據類型
  • 1.經常使用的五大數據類型
  • 2.高級‘玩家’才知道的其餘數據類型
• 3.Redis的持久化
  • 1. RDB (Redis DataBase)
  • 2. AOF
  • 3.總結

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，留着做爲一個萬一的手段。