Redis(Remote Dictionary Server) 是一個(gè)使用 C 語言編寫的，開源的（BSD許可）高性能非關(guān)系型（NoSQL）的鍵值對(duì)數(shù)據(jù)庫。

Redis 可以存儲(chǔ)鍵和五種不同類型的值之間的映射。鍵的類型只能為字符串，值支持五種數(shù)據(jù)類型：字符串、列表、集合、散列表、有序集合。

與傳統(tǒng)數(shù)據(jù)庫不同的是 Redis 的數(shù)據(jù)是存在內(nèi)存中的，所以讀寫速度非常快，因此 redis 被廣泛應(yīng)用于緩存方向，每秒可以處理超過 10萬次讀寫操作，是已知性能最快的Key-Value DB。另外，Redis 也經(jīng)常用來做分布式鎖。除此之外，Redis 支持事務(wù) 、持久化、LUA腳本、LRU驅(qū)動(dòng)事件、多種集群方案。

Redis的優(yōu)點(diǎn)：

1、完全基于內(nèi)存，絕大部分請(qǐng)求是純粹的內(nèi)存操作，非常快速。數(shù)據(jù)存在內(nèi)存中，類似于 HashMap，HashMap 的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)；

2、數(shù)據(jù)結(jié)構(gòu)簡單，對(duì)數(shù)據(jù)操作也簡單，Redis 中的數(shù)據(jù)結(jié)構(gòu)是專門進(jìn)行設(shè)計(jì)的；

3、采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗；

4、使用多路 I/O 復(fù)用模型，非阻塞 IO；

5、使用底層模型不同，它們之間底層實(shí)現(xiàn)方式以及與客戶端之間通信的應(yīng)用協(xié)議不一樣，Redis 直接自己構(gòu)建了 VM 機(jī)制 ，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求；

一：為什么要用 Redis /為什么要用緩存？

主要從“高性能”和“高并發(fā)”這兩點(diǎn)來看待這個(gè)問題。

高性能：

假如用戶第一次訪問數(shù)據(jù)庫中的某些數(shù)據(jù)。這個(gè)過程會(huì)比較慢，因?yàn)槭菑挠脖P上讀取的。將該用戶訪問的數(shù)據(jù)存在數(shù)緩存中，這樣下一次再訪問這些數(shù)據(jù)的時(shí)候就可以直接從緩存中獲取了。操作緩存就是直接操作內(nèi)存，所以速度相當(dāng)快。如果數(shù)據(jù)庫中的對(duì)應(yīng)數(shù)據(jù)改變的之后，同步改變緩存中相應(yīng)的數(shù)據(jù)即可！

高并發(fā)：

直接操作緩存能夠承受的請(qǐng)求是遠(yuǎn)遠(yuǎn)大于直接訪問數(shù)據(jù)庫的，所以我們可以考慮把數(shù)據(jù)庫中的部分?jǐn)?shù)據(jù)轉(zhuǎn)移到緩存中去，這樣用戶的一部分請(qǐng)求會(huì)直接到緩存這里而不用經(jīng)過數(shù)據(jù)庫。

可以看到其主要的作用是為持久化數(shù)據(jù)庫產(chǎn)品降低壓力。但是現(xiàn)實(shí)中其實(shí)有人將redis直接作為數(shù)據(jù)庫使用，這樣其實(shí)是不好的，redis只當(dāng)作緩存用性能好很多。如果想要用內(nèi)存數(shù)據(jù)庫那么有manggo或者h(yuǎn)base這樣的產(chǎn)品來支持。

支持豐富的數(shù)據(jù)類型：

Redis相比其他緩存，有一個(gè)非常大的優(yōu)勢(shì)，就是支持多種數(shù)據(jù)類型。

數(shù)據(jù)類型說明string字符串，最簡單的k-v存儲(chǔ)hashhash格式，value為field和value，適合ID-Detail這樣的場景。list簡單的list，順序列表，支持首位或者末尾插入數(shù)據(jù)set無序list，查找速度快，適合交集、并集、差集處理sorted set有序的set

其實(shí)，通過上面的數(shù)據(jù)類型的特性，基本就能想到合適的應(yīng)用場景了。

• 計(jì)數(shù)器

可以對(duì) String 進(jìn)行自增自減運(yùn)算，從而實(shí)現(xiàn)計(jì)數(shù)器功能。Redis 這種內(nèi)存型數(shù)據(jù)庫的讀寫性能非常高，很適合存儲(chǔ)頻繁讀寫的計(jì)數(shù)量。

• 緩存

將熱點(diǎn)數(shù)據(jù)放到內(nèi)存中，設(shè)置內(nèi)存的最大使用量以及淘汰策略來保證緩存的命中率。

• 會(huì)話緩存

可以使用 Redis 來統(tǒng)一存儲(chǔ)多臺(tái)應(yīng)用服務(wù)器的會(huì)話信息。當(dāng)應(yīng)用服務(wù)器不再存儲(chǔ)用戶的會(huì)話信息，也就不再具有狀態(tài)，一個(gè)用戶可以請(qǐng)求任意一個(gè)應(yīng)用服務(wù)器，從而更容易實(shí)現(xiàn)高可用性以及可伸縮性。

• 全頁緩存（FPC）

除基本的會(huì)話token之外，Redis還提供很簡便的FPC平臺(tái)。以Magento為例，Magento提供一個(gè)插件來使用Redis作為全頁緩存后端。此外，對(duì)WordPress的用戶來說，Pantheon有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過的頁面。

• 查找表

例如 DNS 記錄就很適合使用 Redis 進(jìn)行存儲(chǔ)。查找表和緩存類似，也是利用了 Redis 快速的查找特性。但是查找表的內(nèi)容不能失效，而緩存的內(nèi)容可以失效，因?yàn)榫彺娌蛔鳛榭煽康臄?shù)據(jù)來源。

• 消息隊(duì)列(發(fā)布/訂閱功能)

List 是一個(gè)雙向鏈表，可以通過 lpush 和 rpop 寫入和讀取消息。不過最好使用 Kafka、RabbitMQ 等消息中間件。

• 分布式鎖實(shí)現(xiàn)

在分布式場景下，無法使用單機(jī)環(huán)境下的鎖來對(duì)多個(gè)節(jié)點(diǎn)上的進(jìn)程進(jìn)行同步。可以使用 Redis 自帶的 SETNX 命令實(shí)現(xiàn)分布式鎖，除此之外，還可以使用官方提供的 RedLock 分布式鎖實(shí)現(xiàn)。

• 其它

Set 可以實(shí)現(xiàn)交集、并集等操作，從而實(shí)現(xiàn)共同好友等功能。ZSet 可以實(shí)現(xiàn)有序性操作，從而實(shí)現(xiàn)排行榜等功能。

Redis對(duì)key和value的設(shè)計(jì)是很關(guān)鍵的，包括key的前綴，value的大小

具體規(guī)范可參考阿里云的redis鍵值設(shè)計(jì)規(guī)范

阿里云Redis的規(guī)范：鍵值設(shè)計(jì)、命令使用、工具 - 知乎本文主要介紹在使用阿里云Redis的開發(fā)規(guī)范，從下面幾個(gè)方面進(jìn)行說明。 鍵值設(shè)計(jì)命令使用客戶端使用相關(guān)工具通過本文的介紹可以減少使用Redis過程帶來的問題。 一、鍵值設(shè)計(jì) 1、key名設(shè)計(jì) 可讀性和可管理性以業(yè)務(wù)名…https://zhuanlan.zhihu.com/p/92633604

這里有個(gè)很關(guān)鍵的點(diǎn)：我們生產(chǎn)中有遇到過，redis key或者value設(shè)計(jì)過大導(dǎo)致網(wǎng)絡(luò)堵死的情況，防止網(wǎng)卡流量、慢查詢，string類型控制在10KB以內(nèi)，hash、list、set、zset元素個(gè)數(shù)不要超過5000。

可以好好利用Hash,list,sorted set,set等集合類型數(shù)據(jù)，因?yàn)橥ǔＧ闆r下很多小的Key-Value可以用更緊湊的方式存放到一起。盡可能使用散列表（hashes），散列表（是說散列表里面存儲(chǔ)的數(shù)少）使用的內(nèi)存非常小，所以你應(yīng)該盡可能的將你的數(shù)據(jù)模型抽象到一個(gè)散列表里面。比如你的web系統(tǒng)中有一個(gè)用戶對(duì)象，不要為這個(gè)用戶的名稱，姓氏，郵箱，密碼設(shè)置單獨(dú)的key，而是應(yīng)該把這個(gè)用戶的所有信息存儲(chǔ)到一張散列表里面

二、redis的持久化策略

那么其實(shí)redis為了防了服務(wù)宕機(jī)了內(nèi)存數(shù)據(jù)丟失，其實(shí)有持久化策略。

Redis 提供兩種持久化機(jī)制 RDB（默認(rèn)） 和 AOF 機(jī)制:

RDB：是Redis DataBase縮寫快照（存的數(shù)據(jù)的拷貝）

RDB是Redis默認(rèn)的持久化方式。按照一定的時(shí)間將內(nèi)存的數(shù)據(jù)以快照的形式保存到硬盤中，對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb。通過配置文件中的save參數(shù)來定義快照的周期。

直接建立文件與磁盤的映射，通過零拷貝，直接將數(shù)據(jù)寫入磁盤的一塊連續(xù)存儲(chǔ)內(nèi)，速度會(huì)很快。但是，由于是連續(xù)的，并不適合一直去寫，所以要設(shè)置合適的時(shí)間周期。

優(yōu)點(diǎn)：

• 1、只有一個(gè)文件 dump.rdb，方便持久化。

• 2、容災(zāi)性好，一個(gè)文件可以保存到安全的磁盤。

• 3、性能最大化，fork 子進(jìn)程來完成寫操作，讓主進(jìn)程繼續(xù)處理命令，所以是 IO 最大化。使用單獨(dú)子進(jìn)程來進(jìn)行持久化，主進(jìn)程不會(huì)進(jìn)行任何 IO 操作，保證了 redis 的高性能

• 4.相對(duì)于數(shù)據(jù)集大時(shí)，比 AOF 的啟動(dòng)效率更高。

缺點(diǎn)：

• 1、數(shù)據(jù)安全性低。RDB 是間隔一段時(shí)間進(jìn)行持久化，如果持久化之間 redis 發(fā)生故障，會(huì)發(fā)生數(shù)據(jù)丟失。所以這種方式更適合數(shù)據(jù)要求不嚴(yán)謹(jǐn)?shù)臅r(shí)候)

• 2、AOF（Append-only file)持久化方式：是指所有的命令行記錄以 redis 命令請(qǐng) 求協(xié)議的格式完全持久化存儲(chǔ))保存為 aof 文件。

AOF：持久化（存的是對(duì)數(shù)據(jù)的操作）

AOF持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫命令記錄到單獨(dú)的日志文件中，當(dāng)重啟Redis會(huì)重新將持久化的日志中文件恢復(fù)數(shù)據(jù)。那么既然是日志就會(huì)有大量冗余，并且文件會(huì)更大，那么全量恢復(fù)會(huì)很久。

當(dāng)兩種方式同時(shí)開啟時(shí)，數(shù)據(jù)恢復(fù)Redis會(huì)優(yōu)先選擇AOF恢復(fù)。

優(yōu)點(diǎn)：

• 1、數(shù)據(jù)安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進(jìn)行一次 命令操作就記錄到 aof 文件中一次。

• 2、通過 append 模式寫文件，即使中途服務(wù)器宕機(jī)，可以通過 redis-check-aof 工具解決數(shù)據(jù)一致性問題。

• 3、AOF 機(jī)制的 rewrite 模式。AOF 文件沒被 rewrite 之前（文件過大時(shí)會(huì)對(duì)命令 進(jìn)行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)

缺點(diǎn)：

• 1、AOF 文件比 RDB 文件大，且恢復(fù)速度慢。

• 2、數(shù)據(jù)集大的時(shí)候，比 rdb 啟動(dòng)效率低。

優(yōu)缺點(diǎn)是什么？

• AOF文件比RDB更新頻率高，優(yōu)先使用AOF還原數(shù)據(jù)。

• AOF比RDB更安全也更大

• RDB性能比AOF好

• 如果兩個(gè)都配了優(yōu)先加載AOF

如何選擇合適的持久化方式

• 一般來說， 如果想達(dá)到足以媲美PostgreSQL的數(shù)據(jù)安全性，你應(yīng)該同時(shí)使用兩種持久化功能。在這種情況下，當(dāng) Redis 重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)，因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。

• 如果你非常關(guān)心你的數(shù)據(jù)， 但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，那么你可以只使用RDB持久化。

• 有很多用戶都只使用AOF持久化，但并不推薦這種方式，因?yàn)槎〞r(shí)生成RDB快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫備份， 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比AOF恢復(fù)的速度要快，除此之外，使用RDB還可以避免AOF程序的bug。

• 如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在，你也可以不使用任何持久化方式。

?Redis集群方案

一、主從同步/復(fù)制

通過持久化功能，Redis保證了即使在服務(wù)器重啟的情況下也不會(huì)丟失（或少量丟失）數(shù)據(jù)，因?yàn)槌志没瘯?huì)把內(nèi)存中數(shù)據(jù)保存到硬盤上，重啟會(huì)從硬盤上加載數(shù)據(jù)。 但是由于數(shù)據(jù)是存儲(chǔ)在一臺(tái)服務(wù)器上的，如果這臺(tái)服務(wù)器出現(xiàn)硬盤故障等問題，也會(huì)導(dǎo)致數(shù)據(jù)丟失。

為了避免單點(diǎn)故障，通常的做法是將數(shù)據(jù)庫復(fù)制多個(gè)副本以部署在不同的服務(wù)器上，這樣即使有一臺(tái)服務(wù)器出現(xiàn)故障，其他服務(wù)器依然可以繼續(xù)提供服務(wù)。為此， Redis 提供了復(fù)制（replication）功能，可以實(shí)現(xiàn)當(dāng)一臺(tái)數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動(dòng)將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫上。

在復(fù)制的概念中，數(shù)據(jù)庫分為兩類，一類是主數(shù)據(jù)庫（master），另一類是從數(shù)據(jù)庫(slave）。主數(shù)據(jù)庫可以進(jìn)行讀寫操作，當(dāng)寫操作導(dǎo)致數(shù)據(jù)變化時(shí)會(huì)自動(dòng)將數(shù)據(jù)同步給從數(shù)據(jù)庫。而從數(shù)據(jù)庫一般是只讀的，并接受主數(shù)據(jù)庫同步過來的數(shù)據(jù)。一個(gè)主數(shù)據(jù)庫可以擁有多個(gè)從數(shù)據(jù)庫，而一個(gè)從數(shù)據(jù)庫只能擁有一個(gè)主數(shù)據(jù)庫。

* 主數(shù)據(jù)庫可以進(jìn)行讀寫操作，當(dāng)讀寫操作導(dǎo)致數(shù)據(jù)變化時(shí)會(huì)自動(dòng)將數(shù)據(jù)同步給從數(shù)據(jù)庫
?
* 從數(shù)據(jù)庫一般都是只讀的，并且接收主數(shù)據(jù)庫同步過來的數(shù)據(jù)
?
* 一個(gè)master可以擁有多個(gè)slave，但是一個(gè)slave只能對(duì)應(yīng)一個(gè)master
?
* slave掛了不影響其他slave的讀和master的讀和寫，重新啟動(dòng)后會(huì)將數(shù)據(jù)從master同步過來
?
* master掛了以后，不影響slave的讀，但redis不再提供寫服務(wù)，master重啟后redis將重新對(duì)外提供寫服務(wù)
?
* master掛了以后，不會(huì)在slave節(jié)點(diǎn)中重新選一個(gè)master

?

優(yōu)點(diǎn)：

支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離；
為了分載Master的讀操作壓力，Slave服務(wù)器可以為客戶端提供只讀操作的服務(wù)，寫服務(wù)仍然必須由Master來完成；
Slave同樣可以接受其它Slaves的連接和同步請(qǐng)求，這樣可以有效的分載Master的同步壓力；
Master Server是以非阻塞的方式為Slaves提供服務(wù)。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請(qǐng)求；
Slave Server同樣是以非阻塞的方式完成數(shù)據(jù)同步。在同步期間，如果有客戶端提交查詢請(qǐng)求，Redis則返回同步之前的數(shù)據(jù)；

缺點(diǎn)：

Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)；
主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性；
如果多個(gè)Slave斷線了，需要重啟的時(shí)候，盡量不要在同一時(shí)間段進(jìn)行重啟。因?yàn)橹灰猄lave啟動(dòng)，就會(huì)發(fā)送sync請(qǐng)求和主機(jī)全量同步，當(dāng)多個(gè) Slave 重啟的時(shí)候，可能會(huì)導(dǎo)致 Master IO劇增從而宕機(jī)。
Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜；
二、哨兵模式

第一種主從同步/復(fù)制的模式，當(dāng)主服務(wù)器宕機(jī)后，需要手動(dòng)把一臺(tái)從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費(fèi)事費(fèi)力，還會(huì)造成一段時(shí)間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時(shí)候，我們優(yōu)先考慮哨兵模式。

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個(gè)獨(dú)立的進(jìn)程，作為進(jìn)程，它會(huì)獨(dú)立運(yùn)行。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運(yùn)行的多個(gè)Redis實(shí)例。

?

哨兵模式的作用：

通過發(fā)送命令，讓Redis服務(wù)器返回監(jiān)控其運(yùn)行狀態(tài)，包括主服務(wù)器和從服務(wù)器；
當(dāng)哨兵監(jiān)測(cè)到master宕機(jī)，會(huì)自動(dòng)將slave切換成master，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換主機(jī)；
然而一個(gè)哨兵進(jìn)程對(duì)Redis服務(wù)器進(jìn)行監(jiān)控，也可能會(huì)出現(xiàn)問題，為此，我們可以使用多個(gè)哨兵進(jìn)行監(jiān)控。各個(gè)哨兵之間還會(huì)進(jìn)行監(jiān)控，這樣就形成了多哨兵模式。

?

故障切換的過程：

假設(shè)主服務(wù)器宕機(jī)，哨兵1先檢測(cè)到這個(gè)結(jié)果，系統(tǒng)并不會(huì)馬上進(jìn)行 failover 過程，僅僅是哨兵1主觀的認(rèn)為主服務(wù)器不可用，這個(gè)現(xiàn)象成為主觀下線。當(dāng)后面的哨兵也檢測(cè)到主服務(wù)器不可用，并且數(shù)量達(dá)到一定值時(shí)，那么哨兵之間就會(huì)進(jìn)行一次投票，投票的結(jié)果由一個(gè)哨兵發(fā)起，進(jìn)行 failover 操作。切換成功后，就會(huì)通過發(fā)布訂閱模式，讓各個(gè)哨兵把自己監(jiān)控的從服務(wù)器實(shí)現(xiàn)切換主機(jī)，這個(gè)過程稱為客觀下線。這樣對(duì)于客戶端而言，一切都是透明的。

哨兵模式的工作方式：

每個(gè)Sentinel（哨兵）進(jìn)程以每秒鐘一次的頻率向整個(gè)集群中的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinel（哨兵）進(jìn)程發(fā)送一個(gè) PING 命令。
如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過 down-after-milliseconds 選項(xiàng)所指定的值， 則這個(gè)實(shí)例會(huì)被 Sentinel（哨兵）進(jìn)程標(biāo)記為主觀下線（SDOWN）
如果一個(gè)Master主服務(wù)器被標(biāo)記為主觀下線（SDOWN），則正在監(jiān)視這個(gè)Master主服務(wù)器的所有 Sentinel（哨兵）進(jìn)程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)
當(dāng)有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master主服務(wù)器進(jìn)入了主觀下線狀態(tài)（SDOWN）， 則Master主服務(wù)器會(huì)被標(biāo)記為客觀下線（ODOWN）
在一般情況下， 每個(gè) Sentinel（哨兵）進(jìn)程會(huì)以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令。
當(dāng)Master主服務(wù)器被 Sentinel（哨兵）進(jìn)程標(biāo)記為客觀下線（ODOWN）時(shí)，Sentinel（哨兵）進(jìn)程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次。
若沒有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程同意 Master主服務(wù)器下線， Master主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除。若 Master主服務(wù)器重新向 Sentinel（哨兵）進(jìn)程發(fā)送 PING 命令返回有效回復(fù)，Master主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。

優(yōu)點(diǎn)：

哨兵模式是基于主從模式的，所有主從的優(yōu)點(diǎn)，哨兵模式都具有。
主從可以自動(dòng)切換，系統(tǒng)更健壯，可用性更高。

缺點(diǎn)：

Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。

腦裂現(xiàn)象：

什么是腦裂？

所謂腦裂問題(類似于精神分裂)，就是同一個(gè)集群中的不同節(jié)點(diǎn)，對(duì)于集群的狀態(tài)有了不一樣的理解。

哨兵模式造成的redis腦裂現(xiàn)象原因？

舉例(1主1從2哨兵的情況),由于網(wǎng)絡(luò)原因或者一些特殊原因，哨兵失去了對(duì)master節(jié)點(diǎn)器的感知，將會(huì)通過選舉進(jìn)行故障轉(zhuǎn)移，將slave節(jié)點(diǎn)提升為master節(jié)點(diǎn)，這就導(dǎo)致了當(dāng)前集群中有2個(gè)master，這就是腦裂現(xiàn)象的體現(xiàn)。不同的 client 鏈接到不同的 redis 進(jìn)行讀寫，那么在兩臺(tái)機(jī)器上的 redis 數(shù)據(jù)，就出現(xiàn)了不一致的現(xiàn)象了。當(dāng)哨兵恢復(fù)對(duì)老master節(jié)點(diǎn)的感知后，會(huì)將其降級(jí)為slave節(jié)點(diǎn)，然后從新maste同步數(shù)據(jù)(full resynchronization)，導(dǎo)致腦裂期間老master寫入的數(shù)據(jù)丟失，完?duì)僮恿恕?/p>

解決方案

redis.conf 修改屬性，通過活躍slave節(jié)點(diǎn)數(shù)和數(shù)據(jù)同步延遲時(shí)間來限制master節(jié)點(diǎn)的寫入操作。

# master 至少有 x 個(gè)副本連接。

min-slaves-to-write x

# 數(shù)據(jù)復(fù)制和同步的延遲不能超過 x 秒。

min-slaves-max-lag x

三、Cluster 集群

Redis 的哨兵模式基本已經(jīng)可以實(shí)現(xiàn)高可用，讀寫分離 ，但是在這種模式下每臺(tái) Redis 服務(wù)器都存儲(chǔ)相同的數(shù)據(jù)，很浪費(fèi)內(nèi)存，所以在redis3.0上加入了 Cluster 集群模式，實(shí)現(xiàn)了 Redis 的分布式存儲(chǔ)，也就是說每臺(tái) Redis 節(jié)點(diǎn)上存儲(chǔ)不同的內(nèi)容。

集群的配置

根據(jù)官方推薦，集群部署至少要 3 臺(tái)以上的master節(jié)點(diǎn)，最好使用 3 主 3 從六個(gè)節(jié)點(diǎn)的模式。在測(cè)試環(huán)境中，只能在一臺(tái)機(jī)器上面開啟6個(gè)服務(wù)實(shí)例來模擬。

集群的特點(diǎn)

所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效。

客戶端與 Redis 節(jié)點(diǎn)直連,不需要中間代理層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

所有的節(jié)點(diǎn)都是一主一從（也可以是一主多從），其中從不提供服務(wù)，僅作為備用

支持在線增加、刪除節(jié)點(diǎn)

客戶端可以連接任何一個(gè)主節(jié)點(diǎn)進(jìn)行讀寫

集群的工作方式

在 Redis 的每一個(gè)節(jié)點(diǎn)上，都有這么兩個(gè)東西，一個(gè)是插槽（slot），它的的取值范圍是：0-16383。還有一個(gè)就是cluster，可以理解為是一個(gè)集群管理的插件。當(dāng)我們的存取的 Key到達(dá)的時(shí)候，Redis 會(huì)根據(jù) crc16的算法得出一個(gè)結(jié)果，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0-16383 之間的哈希槽，通過這個(gè)值，去找到對(duì)應(yīng)的插槽所對(duì)應(yīng)的節(jié)點(diǎn)，然后直接自動(dòng)跳轉(zhuǎn)到這個(gè)對(duì)應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作。

Redis 集群使用數(shù)據(jù)分片（sharding）而非一致性哈希（consistency hashing）來實(shí)現(xiàn)： 一個(gè) Redis 集群包含 16384 個(gè)哈希槽（hash slot）， 數(shù)據(jù)庫中的每個(gè)鍵都屬于這 16384 個(gè)哈希槽的其中一個(gè)， 集群使用公式 CRC16(key) % 16384 來計(jì)算鍵 key 屬于哪個(gè)槽， 其中 CRC16(key) 語句用于計(jì)算鍵 key 的 CRC16 校驗(yàn)和 。

集群中的每個(gè)節(jié)點(diǎn)負(fù)責(zé)處理一部分哈希槽。 舉個(gè)例子， 一個(gè)集群可以有三個(gè)哈希槽， 其中：

節(jié)點(diǎn) A 負(fù)責(zé)處理 0 號(hào)至 5500 號(hào)哈希槽。
節(jié)點(diǎn) B 負(fù)責(zé)處理 5501 號(hào)至 11000 號(hào)哈希槽。
節(jié)點(diǎn) C 負(fù)責(zé)處理 11001 號(hào)至 16384 號(hào)哈希槽。
這種將哈希槽分布到不同節(jié)點(diǎn)的做法使得用戶可以很容易地向集群中添加或者刪除節(jié)點(diǎn)。
?

為了保證高可用，redis-cluster集群引入了主從模式，一個(gè)主節(jié)點(diǎn)對(duì)應(yīng)一個(gè)或者多個(gè)從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)宕機(jī)的時(shí)候，就會(huì)啟用從節(jié)點(diǎn)。當(dāng)其它主節(jié)點(diǎn)ping一個(gè)主節(jié)點(diǎn)A時(shí)，如果半數(shù)以上的主節(jié)點(diǎn)與A通信超時(shí)，那么認(rèn)為主節(jié)點(diǎn)A宕機(jī)了。如果主節(jié)點(diǎn)A和它的從節(jié)點(diǎn)A1都宕機(jī)了，那么該集群就無法再提供服務(wù)了。
?

哨兵和集群得區(qū)別

哨兵

哨兵的作用就是監(jiān)控Redis系統(tǒng)的運(yùn)行狀況。它的功能包括以下兩個(gè)。
監(jiān)控主數(shù)據(jù)庫和從數(shù)據(jù)庫是否正常運(yùn)行。
主數(shù)據(jù)庫出現(xiàn)故障時(shí)自動(dòng)將從數(shù)據(jù)庫轉(zhuǎn)換為主數(shù)據(jù)庫。
sentinel發(fā)現(xiàn)master掛了后，就會(huì)從slave中重新選舉一個(gè)master。
哨兵模式強(qiáng)調(diào)高可用
Sentinel 系統(tǒng)用于管理多個(gè) Redis 服務(wù)器（instance）， 該系統(tǒng)執(zhí)行以下三個(gè)任務(wù)：
監(jiān)控（Monitoring）： Sentinel 會(huì)不斷地檢查你的主服務(wù)器和從服務(wù)器是否運(yùn)作正常。
提醒（Notification）： 當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)問題時(shí)， Sentinel 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。
自動(dòng)故障遷移（Automatic failover）： 當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)， Sentinel 會(huì)開始一次自動(dòng)故障遷移操作， 它會(huì)將失效主服務(wù)器的其中一個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器， 并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器； 當(dāng)客戶端試圖連接失效的主服務(wù)器時(shí)， 集群也會(huì)向客戶端返回新主服務(wù)器的地址， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器。
客戶端中不會(huì)記錄redis的地址（某個(gè)IP），而是記錄sentinel的地址，這樣我們可以直接從sentinel獲取的redis地址，因?yàn)閟entinel會(huì)對(duì)所有的master、slave進(jìn)行監(jiān)控，它是知道到底誰才是真正的master的，例如我們故障轉(zhuǎn)移，這時(shí)候?qū)τ趕entinel來說，master是變了的，然后通知客戶端。而客戶端根本不用關(guān)心到底誰才是真正的master，只關(guān)心sentinel告知的master。

集群
即使使用哨兵，redis每個(gè)實(shí)例也是全量存儲(chǔ)，每個(gè)redis存儲(chǔ)的內(nèi)容都是完整的數(shù)據(jù)，浪費(fèi)內(nèi)存且有木桶效應(yīng)。為了最大化利用內(nèi)存，可以采用集群，就是分布式存儲(chǔ)。即每臺(tái)redis存儲(chǔ)不同的內(nèi)容，共有16384個(gè)slot。每個(gè)redis分得一些slot，hash_slot = crc16(key) mod 16384 找到對(duì)應(yīng)slot，鍵是可用鍵，如果有{}則取{}內(nèi)的作為可用鍵，否則整個(gè)鍵是可用鍵
集群至少需要3主3從，且每個(gè)實(shí)例使用不同的配置文件，主從不用配置，集群會(huì)自己選。
cluster是為了解決單機(jī)Redis容量有限的問題，將數(shù)據(jù)按一定的規(guī)則分配到多臺(tái)機(jī)器。
集群模式提高并發(fā)量。

四：緩存異常

緩存雪崩

緩存雪崩是指緩存同一時(shí)間大面積的失效，所以，后面的請(qǐng)求都會(huì)落到數(shù)據(jù)庫上，造成數(shù)據(jù)庫短時(shí)間內(nèi)承受大量請(qǐng)求而崩掉。

解決方案

緩存數(shù)據(jù)的過期時(shí)間設(shè)置隨機(jī)，防止同一時(shí)間大量數(shù)據(jù)過期現(xiàn)象發(fā)生。

一般并發(fā)量不是特別多的時(shí)候，使用最多的解決方案是加鎖排隊(duì)。

給每一個(gè)緩存數(shù)據(jù)增加相應(yīng)的緩存標(biāo)記，記錄緩存的是否失效，如果緩存標(biāo)記失效，則更新數(shù)據(jù)緩存。

緩存穿透

緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù)，導(dǎo)致所有的請(qǐng)求都落到數(shù)據(jù)庫上，造成數(shù)據(jù)庫短時(shí)間內(nèi)承受大量請(qǐng)求而崩掉。

解決方案

接口層增加校驗(yàn)，如用戶鑒權(quán)校驗(yàn)，id做基礎(chǔ)校驗(yàn)，id<=0的直接攔截；

從緩存取不到的數(shù)據(jù)，在數(shù)據(jù)庫中也沒有取到，這時(shí)也可以將key-value對(duì)寫為key-null，緩存有效時(shí)間可以設(shè)置短點(diǎn)，如30秒（設(shè)置太長會(huì)導(dǎo)致正常情況也沒法使用）。這樣可以防止攻擊用戶反復(fù)用同一個(gè)id暴力攻擊

采用布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的 bitmap 中，一個(gè)一定不存在的數(shù)據(jù)會(huì)被這個(gè) bitmap 攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢壓力

附加

對(duì)于空間的利用到達(dá)了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap：典型的就是哈希表

缺點(diǎn)是，Bitmap對(duì)于每個(gè)元素只能記錄1bit信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時(shí)間來完成了。

布隆過濾器（推薦）

就是引入了k(k>1)k(k>1)個(gè)相互獨(dú)立的哈希函數(shù)，保證在給定的空間、誤判率下，完成元素判重的過程。

它的優(yōu)點(diǎn)是空間效率和查詢時(shí)間都遠(yuǎn)遠(yuǎn)超過一般的算法，缺點(diǎn)是有一定的誤識(shí)別率和刪除困難。

Bloom-Filter算法的核心思想就是利用多個(gè)不同的Hash函數(shù)來解決“沖突”。

Hash存在一個(gè)沖突（碰撞）的問題，用同一個(gè)Hash得到的兩個(gè)URL的值有可能相同。為了減少?zèng)_突，我們可以多引入幾個(gè)Hash，如果通過其中的一個(gè)Hash值我們得出某元素不在集合中，那么該元素肯定不在集合中。只有在所有的Hash函數(shù)告訴我們?cè)撛卦诩现袝r(shí)，才能確定該元素存在于集合中。這便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大數(shù)據(jù)量的集合中判定某元素是否存在。

緩存擊穿

緩存擊穿是指緩存中沒有但數(shù)據(jù)庫中有的數(shù)據(jù)（一般是緩存時(shí)間到期），這時(shí)由于并發(fā)用戶特別多，同時(shí)讀緩存沒讀到數(shù)據(jù)，又同時(shí)去數(shù)據(jù)庫去取數(shù)據(jù)，引起數(shù)據(jù)庫壓力瞬間增大，造成過大壓力。和緩存雪崩不同的是，緩存擊穿指并發(fā)查同一條數(shù)據(jù)，緩存雪崩是不同數(shù)據(jù)都過期了，很多數(shù)據(jù)都查不到從而查數(shù)據(jù)庫。

解決方案

設(shè)置熱點(diǎn)數(shù)據(jù)永遠(yuǎn)不過期。

加互斥鎖，互斥鎖

緩存預(yù)熱

緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題！用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)！

解決方案

直接寫個(gè)緩存刷新頁面，上線時(shí)手工操作一下；

數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；

定時(shí)刷新緩存；

緩存降級(jí)

當(dāng)訪問量劇增、服務(wù)出現(xiàn)問題（如響應(yīng)時(shí)間慢或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時(shí)，仍然需要保證服務(wù)還是可用的，即使是有損服務(wù)。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開關(guān)實(shí)現(xiàn)人工降級(jí)。

緩存降級(jí)的最終目的是保證核心服務(wù)可用，即使是有損的。而且有些服務(wù)是無法降級(jí)的（如加入購物車、結(jié)算）。

在進(jìn)行降級(jí)之前要對(duì)系統(tǒng)進(jìn)行梳理，看看系統(tǒng)是不是可以丟卒保帥；從而梳理出哪些必須誓死保護(hù)，哪些可降級(jí)；比如可以參考日志級(jí)別設(shè)置預(yù)案：

一般：比如有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線而超時(shí)，可以自動(dòng)降級(jí)；

警告：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)（如在95~100%之間），可以自動(dòng)降級(jí)或人工降級(jí)，并發(fā)送告警；

錯(cuò)誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問量突然猛增到系統(tǒng)能承受的最大閥值，此時(shí)可以根據(jù)情況自動(dòng)降級(jí)或者人工降級(jí)；

嚴(yán)重錯(cuò)誤：比如因?yàn)樘厥庠驍?shù)據(jù)錯(cuò)誤了，此時(shí)需要緊急人工降級(jí)。

服務(wù)降級(jí)的目的，是為了防止Redis服務(wù)故障，導(dǎo)致數(shù)據(jù)庫跟著一起發(fā)生雪崩問題。因此，對(duì)于不重要的緩存數(shù)據(jù)，可以采取服務(wù)降級(jí)策略，例如一個(gè)比較常見的做法就是，Redis出現(xiàn)問題，不去數(shù)據(jù)庫查詢，而是直接返回默認(rèn)值給用戶。

熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)

熱點(diǎn)數(shù)據(jù)，緩存才有價(jià)值

對(duì)于冷數(shù)據(jù)而言，大部分?jǐn)?shù)據(jù)可能還沒有再次訪問到就已經(jīng)被擠出內(nèi)存，不僅占用內(nèi)存，而且價(jià)值不大。頻繁修改的數(shù)據(jù)，看情況考慮使用緩存

對(duì)于熱點(diǎn)數(shù)據(jù)，比如我們的某IM產(chǎn)品，生日祝福模塊，當(dāng)天的壽星列表，緩存以后可能讀取數(shù)十萬次。再舉個(gè)例子，某導(dǎo)航產(chǎn)品，我們將導(dǎo)航信息，緩存以后可能讀取數(shù)百萬次。

數(shù)據(jù)更新前至少讀取兩次，緩存才有意義。這個(gè)是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價(jià)值了。

那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個(gè)讀取接口對(duì)數(shù)據(jù)庫的壓力很大，但是又是熱點(diǎn)數(shù)據(jù)，這個(gè)時(shí)候就需要考慮通過緩存手段，減少數(shù)據(jù)庫的壓力，比如我們的某助手產(chǎn)品的，點(diǎn)贊數(shù)，收藏?cái)?shù)，分享數(shù)等是非常典型的熱點(diǎn)數(shù)據(jù)，但是又不斷變化，此時(shí)就需要將數(shù)據(jù)同步保存到Redis緩存，減少數(shù)據(jù)庫壓力。

緩存熱點(diǎn)key

緩存中的一個(gè)Key(比如一個(gè)促銷商品)，在某個(gè)時(shí)間點(diǎn)過期的時(shí)候，恰好在這個(gè)時(shí)間點(diǎn)對(duì)這個(gè)Key有大量的并發(fā)請(qǐng)求過來，這些請(qǐng)求發(fā)現(xiàn)緩存過期一般都會(huì)從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個(gè)時(shí)候大并發(fā)的請(qǐng)求可能會(huì)瞬間把后端DB壓垮。

解決方案

對(duì)緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進(jìn)程如果發(fā)現(xiàn)有鎖就等待，然后等解鎖后返回?cái)?shù)據(jù)或者進(jìn)入DB查詢

五、如何保證緩存與數(shù)據(jù)庫雙寫時(shí)的數(shù)據(jù)一致性？

你只要用緩存，就可能會(huì)涉及到緩存與數(shù)據(jù)庫雙存儲(chǔ)雙寫，你只要是雙寫，就一定會(huì)有數(shù)據(jù)一致性的問題，那么你如何解決一致性問題？

一般來說，就是如果你的系統(tǒng)不是嚴(yán)格要求緩存+數(shù)據(jù)庫必須一致性的話，緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的情況，最好不要做這個(gè)方案，讀請(qǐng)求和寫請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣就可以保證一定不會(huì)出現(xiàn)不一致的情況

串行化之后，就會(huì)導(dǎo)致系統(tǒng)的吞吐量會(huì)大幅度的降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。

還有一種方式就是可能會(huì)暫時(shí)產(chǎn)生不一致的情況，但是發(fā)生的幾率特別小，就是先更新數(shù)據(jù)庫，然后再刪除緩存。

Redis常見性能問題和解決方案？

Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化。

如果數(shù)據(jù)比較關(guān)鍵，某個(gè)Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。

為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個(gè)局域網(wǎng)內(nèi)。

盡量避免在壓力較大的主庫上增加從庫

Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時(shí)候會(huì)占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫停現(xiàn)象。

為了Master的穩(wěn)定性，主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更穩(wěn)定，即主從關(guān)系為：Master<–Slave1<–Slave2<–Slave3…，這樣的結(jié)構(gòu)也方便解決單點(diǎn)故障問題，實(shí)現(xiàn)Slave對(duì)Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。

六、過期鍵的刪除策略

Redis的過期鍵的刪除策略

我們都知道，Redis是key-value數(shù)據(jù)庫，我們可以設(shè)置Redis中緩存的key的過期時(shí)間。Redis的過期策略就是指當(dāng)Redis中緩存的key過期了，Redis如何處理。

過期策略通常有以下三種：

• 定時(shí)過期：每個(gè)設(shè)置過期時(shí)間的key都需要?jiǎng)?chuàng)建一個(gè)定時(shí)器，到過期時(shí)間就會(huì)立即清除。該策略可以立即清除過期的數(shù)據(jù)，對(duì)內(nèi)存很友好；但是會(huì)占用大量的CPU資源去處理過期的數(shù)據(jù)，從而影響緩存的響應(yīng)時(shí)間和吞吐量。

• 惰性過期：只有當(dāng)訪問一個(gè)key時(shí)，才會(huì)判斷該key是否已過期，過期則清除。該策略可以最大化地節(jié)省CPU資源，卻對(duì)內(nèi)存非常不友好。極端情況可能出現(xiàn)大量的過期key沒有再次被訪問，從而不會(huì)被清除，占用大量內(nèi)存。

• 定期過期：每隔一定的時(shí)間，會(huì)掃描一定數(shù)量的數(shù)據(jù)庫的expires字典中一定數(shù)量的key，并清除其中已過期的key。該策略是前兩者的一個(gè)折中方案。通過調(diào)整定時(shí)掃描的時(shí)間間隔和每次掃描的限定耗時(shí)，可以在不同情況下使得CPU和內(nèi)存資源達(dá)到最優(yōu)的平衡效果。
  (expires字典會(huì)保存所有設(shè)置了過期時(shí)間的key的過期時(shí)間數(shù)據(jù)，其中，key是指向鍵空間中的某個(gè)鍵的指針，value是該鍵的毫秒精度的UNIX時(shí)間戳表示的過期時(shí)間。鍵空間是指該Redis集群中保存的所有鍵。)

Redis中同時(shí)使用了惰性過期和定期過期兩種過期策略。

Redis key的過期時(shí)間和永久有效分別怎么設(shè)置？

EXPIRE和PERSIST命令。

我們知道通過expire來設(shè)置key 的過期時(shí)間，那么對(duì)過期的數(shù)據(jù)怎么處理呢?

除了緩存服務(wù)器自帶的緩存失效策略之外（Redis默認(rèn)的有6中策略可供選擇），我們還可以根據(jù)具體的業(yè)務(wù)需求進(jìn)行自定義的緩存淘汰，常見的策略有兩種：

定時(shí)去清理過期的緩存；

當(dāng)有用戶請(qǐng)求過來時(shí)，再判斷這個(gè)請(qǐng)求所用到的緩存是否過期，過期的話就去底層系統(tǒng)得到新數(shù)據(jù)并更新緩存。

兩者各有優(yōu)劣，第一種的缺點(diǎn)是維護(hù)大量緩存的key是比較麻煩的，第二種的缺點(diǎn)就是每次用戶請(qǐng)求過來都要判斷緩存失效，邏輯相對(duì)比較復(fù)雜！具體用哪種方案，大家可以根據(jù)自己的應(yīng)用場景來權(quán)衡。

參考：

redis的三種集群模式原理_wr_java的博客-CSDN博客

?Redis 常見面試題（2020最新版） - Java知音號(hào) - 博客園

總結(jié)

以上是生活随笔為你收集整理的「中间件系列二」redis缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。