Redis 資料結構

Redis 常用的資料型別主要有以下五種：

• String

• Hash

• List

• Set

• Sorted set

Redis 內部使用一個 redisObject 物件來表示所有的 key 和 value。

String 在 redis 內部儲存預設就是一個字串，被 redisObject 所引用，當遇到 incr，decr 等操作時會轉成數值型進行計算，此時 redisObject 的 encoding 欄位為int。

list 的實現為一個雙向連結串列，即可以支援反向查詢和遍歷，更方便操作，不過帶來了部分額外的記憶體開銷，Redis 內部的很多實現，包括髮送緩衝佇列等也都是用的這個資料結構。

Hash 對應 Value 內部實際就是一個 HashMap，實際這裡會有2種不同實現，這個 Hash 的成員比較少時 Redis 為了節省記憶體會採用類似一維陣列的方式來緊湊儲存，而不會採用真正的 HashMap 結構，對應的 value redisObject 的 encoding 為 zipmap，當成員數量增大時會自動轉成真正的 HashMap，此時 encoding 為 ht。

Redis 儲存

Redis 提供了一系列不同的永續性選項：

• RDB  永續性以指定的時間間隔執行資料集的時間點快照。

• AOF 永續性會記錄伺服器接收到的每個寫入操作，這些操作將在伺服器啟動時再次執行，重建原始資料集。使用與Redis協議本身相同的格式以追加方式記錄命令。

RDB的優點：

• RDB是Redis資料的非常緊湊的單檔案時間點表示。

• RDB檔案非常適合備份。

RDB的缺點：

• 快照不是非常耐用。如果執行Redis的計算機停止執行，電源線出現故障，或者意外地終止了您的例項，寫入Redis的最新資料將丟失。

• 為了使用子程序在磁碟上保留RDB，RDB需要經常fork。如果資料集很大，Fork會很費時，並且可能導致Redis在幾毫秒內停止服務客戶端，或者如果資料集非常大並且CPU效能不佳，甚至會持續一秒。

Redis 需要將資料集轉儲到磁碟時，會發生以下情況：

• Redis fork。我們現在有一個子程序和一個父程序。

• 子程序開始將資料集寫入臨時RDB檔案。

• 當子程序寫完新的RDB檔案後，它會替換舊的。

AOF的優勢：

AOF日誌是一種只能追加的日誌，因此如果發生停電，也不會出現問題。

AOF的缺點：

• AOF檔案通常比相同資料集的等效RDB檔案大。

• 根據確切的fsync策略，AOF可能比RDB慢。

Redis將在磁碟上同步資料的次數。有三種選擇：

• 每當一個新命令被附加到AOF時，fsync。非常非常緩慢，非常安全。

• 每秒fsync。足夠快（在2.4可能與快照一樣快），並且如果發生災難，您可能會丟失1秒的資料。

• 永遠不要fsync，只需將您的資料交給作業系統即可。更快，不安全的方法。

日誌重寫使用已用於快照的相同的寫入時複製技巧。這是如何工作的：

• Redis fork，所以現在我們有子程序和一個父程序。

• 子程序開始在臨時檔案中寫入新的AOF

• 父程序將所有新的更改累積到記憶體緩衝區中

• 當子程序完成重寫檔案時，父程序獲取訊號，並在子程序生成的檔案末尾追加記憶體緩衝區的內容。

• Redis自動將舊檔案重新命名為新檔案，並開始將新資料附加到新檔案中。

Redis 事務

Redis 提供的事務機制與傳統的資料庫事務有些不同，傳統資料庫事務必須維護以下特性：原子性（Atomicity），一致性（Consistency），隔離性（Isolation），永續性（Durability），簡稱ACID。

原子性（Atomicity）
Redis 本身提供的所有 API 都是原子操作。

但 Redis 在事務執行過程的錯誤情況做出了權衡取捨，那就是放棄了回滾。

Redis 官方文件對此給出的解釋是：

1、Redis 操作失敗的原因只可能是語法錯誤或者錯誤的資料庫型別操作，這些都是在開發層面能發現的問題不會進入到生產環境，因此不需要回滾。

2、Redis 內部設計推崇簡單和高效能，因此不需要回滾能力。

一致性（Consistency）
一致性意味著事務結束後系統的資料依然保證一致。

Redis 捨棄了回滾的設計，基本上也就捨棄對資料一致性的有效保證。

隔離性（Isolation）

隔離性保證了在事務完成之前，該事務外部不能看到事務裡的資料改變。

Redis 採用單執行緒設計，隔離性得到保證。

永續性（Durability）

Redis 一般情況下都只進行記憶體計算和操作，永續性無法保證。

但 Redis 也提供了2種資料持久化模式，RDB 和 AOF，RDB 的持久化操作與命令操作是不同步的，無法保證事務的永續性。而 AOF 模式意味著每條命令的執行都需要進行系統呼叫操作磁碟寫入檔案，可以保證永續性，但會大大降低 Redis 的訪問效能。

Redis 主從

Redis的主從結構可以採用一主多從或者級聯結構：

全量同步

Redis全量複製一般發生在Slave初始化階段，這時Slave需要將Master上的所有資料都複製一份。

具體步驟如下：

1）從伺服器連線主伺服器，傳送SYNC命令；

2）主伺服器接收到SYNC命名後，開始執行BGSAVE命令生成RDB檔案並使用緩衝區記錄此後執行的所有寫命令；

3）主伺服器BGSAVE執行完後，向所有從伺服器傳送快照檔案，並在傳送期間繼續記錄被執行的寫命令；

4）從伺服器收到快照檔案後丟棄所有舊資料，載入收到的快照；

5）主伺服器快照發送完畢後開始向從伺服器傳送緩衝區中的寫命令；

6）從伺服器完成對快照的載入，開始接收命令請求，並執行來自主伺服器緩衝區的寫命令

增量同步

Redis增量複製是指Slave初始化後開始正常工作時主伺服器發生的寫操作同步到從伺服器的過程。

增量複製的過程主要是主伺服器每執行一個寫命令就會向從伺服器傳送相同的寫命令，從伺服器接收並執行收到的寫命令。

Redis 場景

常見的 NoSQL 方案分為 4 類。

• K-V 儲存：解決關係資料庫無法儲存資料結構的問題，以 Redis 為代表。

• 文件資料庫：解決關係資料庫強 schema 約束的問題，以 MongoDB 為代表。

• 列式資料庫：解決關係資料庫大資料場景下的 I/O 問題，以 HBase 為代表。

• 全文搜尋引擎：解決關係資料庫的全文搜尋效能問題，以 Elasticsearch 為代表。

快取的架構設計要點：

快取穿透是指快取沒有發揮作用，業務系統雖然去快取查詢資料，但快取中沒有資料，業務系統需要再次去儲存系統查詢資料。

通常情況下有兩種情況：

• 1、儲存資料不存在

• 2、快取資料生成耗費大量時間或者資源

快取雪崩是指當快取失效（過期）後引起系統性能急劇下降的情況。

快取熱點的解決方案就是複製多份快取副本，將請求分散到多個快取伺服器上，減輕快取熱點導致的單臺快取伺服器壓力。

首頁分流載入