1. 程式人生 > >Redis學習記錄

Redis學習記錄

經歷 停止工作 切換 http 基本類 cache 數據保存 map 策略

參考資料:

http://www.dengshenyu.com/%E5%90%8E%E7%AB%AF%E6%8A%80%E6%9C%AF/2016/01/09/redis-reactor-pattern.html
http://www.redis.cn/topics/data-types.html
http://www.syyong.com/db/Redis-why-the-use-of-single-process-and-single-threaded-way-so-fast.html
https://toutiao.io/posts/546542/app_preview
http://ifeve.com/redis-persistence/

0. 環境

Redis server: 3.0.3

1. 數據類型

  • 字符串(Strings)

字符串是一種最基本的Redis值類型。Redis字符串是二進制安全的,這意味著一個Redis字符串能包含任意類型的數據。一個字符串類型的值最多能存儲512M字節的內容。

  • 列表(Lists)

Redis列表是簡單的字符串列表,按照插入順序排序。

  • 集合(Sets)

Redis集合是一個無序的字符串合集。添加、刪除以及測試元素是否存在操作的時間復雜度為O(1)。

  • 哈希(Hashes)

Redis Hashes是字符串字段和字符串值之間的映射,所以它們是完美的表示對象的數據類型。

  • 有序集合(Sorted sets)

Redis有序集合和Redis集合類似,是不包含相同字符串的合集。但每個有序集合的成員都關聯著一個評分,這個評分用於把有序集合中的成員按最低分到最高分排列。

  • Bitmaps 和 HyperLogLogs

Redis同樣支持Bitmaps和HyperLogLogs數據類型,實際上是基於字符串的基本類型的數據類型,但有自己的語義。

2. Redis為什麽速度快?

  • 完全基於內存
  • 單線程:CPU無需在多個線程之間來回切換
  • I/O多路復用技術:異步非阻塞IO,既不會因為線程過多導致CPU頻繁切換,又能充分利用服務器資源

3. Redis超時及應對方法?

  • 慢查詢:確認是否使用慢查詢,可以使用slowlog get num查看相應的慢命令
  • 內存使用情況:由於Redis完全基於內存,故這個指標需要關註
  • 連接客戶端數量:若連接客戶端數量超過默認值容易導致超時
  • 查看redis主機是否為虛擬機,這樣會有內存延遲:./redis-cli --intrinsic-latency 100這個命令可以在server端進行判斷是否redis有延遲,在客戶端通過-h -p 參數可以進行對比一下是否為網絡上的影響
  • 一般情況下大量的刪除、過期以及淘汰(由maxmemory-policy控制的)的大對象,也會造成redis阻塞,進而造成相應的延遲:經常有比較大的對象進行刪除、過期和淘汰的,建議將這些對象分割成一些小對象。
  • 持久化導致延遲,因為持久化是把數據保存到磁盤中,IO操作占用大量CPU資源可能導致Redis無法得到執行時間:選擇更合理的持久化方案,例如AOF + fsync every second

4. Redis持久化及其優缺點

  • RDB持久化:可以在指定的時間間隔內生成數據集的時間點快照
  • AOF持久化:記錄服務器執行的所有寫操作命令,並在服務器啟動時,通過重新執行這些命令來還原數據集
優點 缺點
RDB
  1. RDB是一種表示某個即時點的Redis數據的緊湊文件。RDB文件適合用於備份。
  2. RDB非常適合於災難恢復,作為一個緊湊的單一文件,可以被傳輸到遠程的數據中心。
  3. RDB最大化了Redis的性能,因為Redis父進程持久化時唯一需要做的是啟動(fork)一個子進程,由子進程完成所有剩余工作。父進程實例不需要執行像磁盤IO這樣的操作。
  4. RDB在重啟保存了大數據集的實例時比AOF要快。
  1. 當你需要在Redis停止工作(例如停電)時最小化數據丟失,RDB可能不太好。你可以配置不同的保存點(save point)來保存RDB文件(例如,至少5分鐘和對數據集100次寫之後,但是你可以有多個保存點)。然而,你通常每隔5分鐘或更久創建一個RDB快照,所以一旦Redis因為任何原因沒有正確關閉而停止工作,你就得做好最近幾分鐘數據丟失的準備了。
  2. RDB需要經常調用fork()子進程來持久化到磁盤。如果數據集很大的話,fork()比較耗時,結果就是,當數據集非常大並且CPU性能不夠強大的話,Redis會停止服務客戶端幾毫秒甚至一秒。AOF也需要fork(),但是你可以調整多久頻率重寫日誌而不會有損(trade-off)持久性(durability)。
AOF
  1. 使用AOF Redis會更具有可持久性(durable):你可以有很多不同的fsync策略:沒有fsync,每秒fsync,每次請求時fsync。使用默認的每秒fsync策略,寫性能也仍然很不錯(fsync是由後臺線程完成的,主線程繼續努力地執行寫請求),即便你也就僅僅只損失一秒鐘的寫數據。
  2. AOF日誌是一個追加文件,所以不需要定位,在斷電時也沒有損壞問題。即使由於某種原因文件末尾是一個寫到一半的命令(磁盤滿或者其他原因),redis-check-aof工具也可以很輕易的修復。
  3. 當AOF文件變得很大時,Redis會自動在後臺進行重寫。重寫是絕對安全的,因為Redis繼續往舊的文件中追加,使用創建當前數據集所需的最小操作集合來創建一個全新的文件,一旦第二個文件創建完畢,Redis就會切換這兩個文件,並開始往新文件追加。
  4. AOF文件裏面包含一個接一個的操作,以易於理解和解析的格式存儲。你也可以輕易的導出一個AOF文件。例如,即使你不小心錯誤地使用FLUSHALL命令清空一切,如果此時並沒有執行重寫,你仍然可以保存你的數據集,你只要停止服務器,刪除最後一條命令,然後重啟Redis就可以。
  1. 對同樣的數據集,AOF文件通常要大於等價的RDB文件。
  2. AOF可能比RDB慢,這取決於準確的fsync策略。通常fsync設置為每秒一次的話性能仍然很高,如果關閉fsync,即使在很高的負載下也和RDB一樣的快。不過,即使在很大的寫負載情況下,RDB還是能提供能好的最大延遲保證。
  3. 在過去,我們經歷了一些針對特殊命令(例如,像BRPOPLPUSH這樣的阻塞命令)的罕見bug,導致在數據加載時無法恢復到保存時的樣子。

5. Redis與Memcached的區別

  • 實現機制不同:Redis單進程單線程,Memcached單進程多線程
  • 持久化策略不同:Redis支持持久化,Memcached必須借助外部工具才能實現持久化
  • Redis功能比Memcached更強大,Redis不僅僅是內存數據庫(例如可利用Pub/Sub實現發布訂閱的消息中間件),而Memcached僅僅是內存數據庫

Redis學習記錄