深刻淺出告訴你Redis的高級特性

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 官方文檔對此給出的解釋是：

一、Redis 操做失敗的緣由只多是語法錯誤或者錯誤的數據庫類型操做，這些都是在開發層面能發現的問題不會進入到生產環境，所以不須要回滾。

二、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 爲表明。

緩存的架構設計要點：

緩存穿透是指緩存沒有發揮做用，業務系統雖然去緩存查詢數據，但緩存中沒有數據，業務系統須要再次去存儲系統查詢數據。

一般狀況下有兩種狀況：

一、存儲數據不存在

二、緩存數據生成耗費大量時間或者資源

緩存雪崩是指當緩存失效(過時)後引發系統性能急劇降低的狀況。

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

讀寫分離+多級緩存策略

首頁分流加載