深入淺出聊聊 Redis 高級特性
Redis 數(shù)據(jù)結(jié)構(gòu)
Redis 常用的數(shù)據(jù)類型主要有以下五種:
- String
 - Hash
 - List
 - Set
 - Sorted set
 
Redis 內(nèi)部使用一個 redisObject 對象來表示所有的 key 和 value。
String 在 redis 內(nèi)部存儲默認(rèn)就是一個字符串,被 redisObject 所引用,當(dāng)遇到 incr,decr 等操作時會轉(zhuǎn)成數(shù)值型進行計算,此時 redisObject 的 encoding 字段為int。
list 的實現(xiàn)為一個雙向鏈表,即可以支持反向查找和遍歷,更方便操作,不過帶來了部分額外的內(nèi)存開銷,Redis 內(nèi)部的很多實現(xiàn),包括發(fā)送緩沖隊列等也都是用的這個數(shù)據(jù)結(jié)構(gòu)。
Hash 對應(yīng) Value 內(nèi)部實際就是一個 HashMap,實際這里會有2種不同實現(xiàn),這個 Hash 的成員比較少時 Redis 為了節(jié)省內(nèi)存會采用類似一維數(shù)組的方式來緊湊存儲,而不會采用真正的 HashMap 結(jié)構(gòu),對應(yīng)的 value redisObject 的 encoding 為 zipmap,當(dāng)成員數(shù)量增大時會自動轉(zhuǎn)成真正的 HashMap,此時 encoding 為 ht。
Redis 存儲
Redis 提供了一系列不同的持久性選項:
- RDB 持久性以指定的時間間隔執(zhí)行數(shù)據(jù)集的時間點快照。
 - AOF 持久性會記錄服務(wù)器接收到的每個寫入操作,這些操作將在服務(wù)器啟動時再次執(zhí)行,重建原始數(shù)據(jù)集。使用與Redis協(xié)議本身相同的格式以追加方式記錄命令。
 
RDB的優(yōu)點:
- RDB是Redis數(shù)據(jù)的非常緊湊的單文件時間點表示。
 - RDB文件非常適合備份。
 
RDB的缺點:
- 快照不是非常耐用。如果運行Redis的計算機停止運行,電源線出現(xiàn)故障,或者意外地終止了您的實例,寫入Redis的最新數(shù)據(jù)將丟失。
 - 為了使用子進程在磁盤上保留RDB,RDB需要經(jīng)常fork。如果數(shù)據(jù)集很大,F(xiàn)ork會很費時,并且可能導(dǎo)致Redis在幾毫秒內(nèi)停止服務(wù)客戶端,或者如果數(shù)據(jù)集非常大并且CPU性能不佳,甚至?xí)掷m(xù)一秒。
 
Redis 需要將數(shù)據(jù)集轉(zhuǎn)儲到磁盤時,會發(fā)生以下情況:
- Redis fork。我們現(xiàn)在有一個子進程和一個父進程。
 - 子進程開始將數(shù)據(jù)集寫入臨時RDB文件。
 - 當(dāng)子進程寫完新的RDB文件后,它會替換舊的。
 
AOF的優(yōu)勢:
AOF日志是一種只能追加的日志,因此如果發(fā)生停電,也不會出現(xiàn)問題。
AOF的缺點:
- AOF文件通常比相同數(shù)據(jù)集的等效RDB文件大。
 - 根據(jù)確切的fsync策略,AOF可能比RDB慢。
 
Redis將在磁盤上同步數(shù)據(jù)的次數(shù)。有三種選擇:
- 每當(dāng)一個新命令被附加到AOF時,fsync。非常非常緩慢,非常安全。
 - 每秒fsync。足夠快(在2.4可能與快照一樣快),并且如果發(fā)生災(zāi)難,您可能會丟失1秒的數(shù)據(jù)。
 - 永遠(yuǎn)不要fsync,只需將您的數(shù)據(jù)交給操作系統(tǒng)即可。更快,不安全的方法。
 
日志重寫使用已用于快照的相同的寫入時復(fù)制技巧。這是如何工作的:
- Redis fork,所以現(xiàn)在我們有子進程和一個父進程。
 - 子進程開始在臨時文件中寫入新的AOF
 - 父進程將所有新的更改累積到內(nèi)存緩沖區(qū)中
 - 當(dāng)子進程完成重寫文件時,父進程獲取信號,并在子進程生成的文件末尾追加內(nèi)存緩沖區(qū)的內(nèi)容。
 - Redis自動將舊文件重命名為新文件,并開始將新數(shù)據(jù)附加到新文件中。
 
Redis 事務(wù)
Redis 提供的事務(wù)機制與傳統(tǒng)的數(shù)據(jù)庫事務(wù)有些不同,傳統(tǒng)數(shù)據(jù)庫事務(wù)必須維護以下特性:原子性(Atomicity),一致性(Consistency),隔離性(Isolation),持久性(Durability),簡稱ACID。
原子性(Atomicity)
Redis 本身提供的所有 API 都是原子操作。
但 Redis 在事務(wù)執(zhí)行過程的錯誤情況做出了權(quán)衡取舍,那就是放棄了回滾。
Redis 官方文檔對此給出的解釋是:
1、Redis 操作失敗的原因只可能是語法錯誤或者錯誤的數(shù)據(jù)庫類型操作,這些都是在開發(fā)層面能發(fā)現(xiàn)的問題不會進入到生產(chǎn)環(huán)境,因此不需要回滾。
2、Redis 內(nèi)部設(shè)計推崇簡單和高性能,因此不需要回滾能力。
一致性(Consistency)
一致性意味著事務(wù)結(jié)束后系統(tǒng)的數(shù)據(jù)依然保證一致。
Redis 舍棄了回滾的設(shè)計,基本上也就舍棄對數(shù)據(jù)一致性的有效保證。
隔離性(Isolation)
隔離性保證了在事務(wù)完成之前,該事務(wù)外部不能看到事務(wù)里的數(shù)據(jù)改變。
Redis 采用單線程設(shè)計,隔離性得到保證。
持久性(Durability)
Redis 一般情況下都只進行內(nèi)存計算和操作,持久性無法保證。
但 Redis 也提供了2種數(shù)據(jù)持久化模式,RDB 和 AOF,RDB 的持久化操作與命令操作是不同步的,無法保證事務(wù)的持久性。而 AOF 模式意味著每條命令的執(zhí)行都需要進行系統(tǒng)調(diào)用操作磁盤寫入文件,可以保證持久性,但會大大降低 Redis 的訪問性能。
Redis 主從
Redis的主從結(jié)構(gòu)可以采用一主多從或者級聯(lián)結(jié)構(gòu):
全量同步
Redis全量復(fù)制一般發(fā)生在Slave初始化階段,這時Slave需要將Master上的所有數(shù)據(jù)都復(fù)制一份。
具體步驟如下:
1)從服務(wù)器連接主服務(wù)器,發(fā)送SYNC命令;
2)主服務(wù)器接收到SYNC命名后,開始執(zhí)行BGSAVE命令生成RDB文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令;
3)主服務(wù)器BGSAVE執(zhí)行完后,向所有從服務(wù)器發(fā)送快照文件,并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令;
4)從服務(wù)器收到快照文件后丟棄所有舊數(shù)據(jù),載入收到的快照;
5)主服務(wù)器快照發(fā)送完畢后開始向從服務(wù)器發(fā)送緩沖區(qū)中的寫命令;
6)從服務(wù)器完成對快照的載入,開始接收命令請求,并執(zhí)行來自主服務(wù)器緩沖區(qū)的寫命令
增量同步
Redis增量復(fù)制是指Slave初始化后開始正常工作時主服務(wù)器發(fā)生的寫操作同步到從服務(wù)器的過程。
增量復(fù)制的過程主要是主服務(wù)器每執(zhí)行一個寫命令就會向從服務(wù)器發(fā)送相同的寫命令,從服務(wù)器接收并執(zhí)行收到的寫命令。
Redis 場景
常見的 NoSQL 方案分為 4 類。
- K-V 存儲:解決關(guān)系數(shù)據(jù)庫無法存儲數(shù)據(jù)結(jié)構(gòu)的問題,以 Redis 為代表。
 - 文檔數(shù)據(jù)庫:解決關(guān)系數(shù)據(jù)庫強 schema 約束的問題,以 MongoDB 為代表。
 - 列式數(shù)據(jù)庫:解決關(guān)系數(shù)據(jù)庫大數(shù)據(jù)場景下的 I/O 問題,以 HBase 為代表。
 - 全文搜索引擎:解決關(guān)系數(shù)據(jù)庫的全文搜索性能問題,以 Elasticsearch 為代表。
 
緩存的架構(gòu)設(shè)計要點:
緩存穿透是指緩存沒有發(fā)揮作用,業(yè)務(wù)系統(tǒng)雖然去緩存查詢數(shù)據(jù),但緩存中沒有數(shù)據(jù),業(yè)務(wù)系統(tǒng)需要再次去存儲系統(tǒng)查詢數(shù)據(jù)。
通常情況下有兩種情況:
- 1、存儲數(shù)據(jù)不存在
 - 2、緩存數(shù)據(jù)生成耗費大量時間或者資源
 
緩存雪崩是指當(dāng)緩存失效(過期)后引起系統(tǒng)性能急劇下降的情況。
緩存熱點的解決方案就是復(fù)制多份緩存副本,將請求分散到多個緩存服務(wù)器上,減輕緩存熱點導(dǎo)致的單臺緩存服務(wù)器壓力。
讀寫分離+多級緩存策略
首頁分流加載






















 
 
 









 
 
 
 