Redis你能跟面試官聊哪些？

簡(jiǎn)介：以上文章講述的是【數(shù)據(jù)庫(kù)性能調(diào)優(yōu)知識(shí)與面試知識(shí)（詳解四服務(wù)器性能剖析）】接下來(lái)我總結(jié)一下【Redis入門(mén)知識(shí)點(diǎn)】。覺(jué)得我還可以的可以加群一起督促學(xué)習(xí)探討技術(shù)。QQ群：1076570504 個(gè)人學(xué)習(xí)資料庫(kù)http://www.aolanghs.com/?微信公眾號(hào)搜索【歡少的成長(zhǎng)之路】

• Redis是什么？為什么選擇Redis？

• 與Redis類似的系統(tǒng)有哪些？挑選一個(gè)你比較熟悉的簡(jiǎn)單講解一下？

• Redis的五大數(shù)據(jù)類型應(yīng)用場(chǎng)景都是什么？

• 以上講述了五大類型，Java里完全也可以實(shí)現(xiàn)，為什么非要用Redis來(lái)替代呢？

• 一直往Redis里加數(shù)據(jù)，不會(huì)溢出嗎？它又是怎么刪除的呢？

• Redis與數(shù)據(jù)庫(kù)作交互，例如MySQL，它有事務(wù)，Redis有事務(wù)嗎？跟MySQL事務(wù)有什么區(qū)別？

• 提到Redis很多文章會(huì)提壓縮表與跳躍表，這兩個(gè)又是什么東東？

• 講述一下Redis的內(nèi)存淘汰機(jī)制？

• 內(nèi)存打滿或者電腦癱瘓如何保證數(shù)據(jù)的有效性？

• 應(yīng)用場(chǎng)景中你遇到過(guò)哪些問(wèn)題呢？這些你又是怎么解決的？

• Redis集群有哪幾種模式？可以簡(jiǎn)單介紹一下嗎？

• Redis如何解決并發(fā)的？

• Redis用在分布式的話又會(huì)遇到哪些問(wèn)題呢？

TIP：通過(guò)這篇文章你能學(xué)習(xí)到這些知識(shí)！想了解的繼續(xù)深入，不想了解的趕緊離開(kāi)，我不想浪費(fèi)你們的學(xué)習(xí)時(shí)間。找準(zhǔn)自己的定位與目標(biāo)，堅(jiān)持下去，并且一定要高效。我跟你們一樣非常抵制垃圾文章，雷同文章，胡說(shuō)八道的文章。

很多人會(huì)問(wèn)，學(xué)底層多浪費(fèi)時(shí)間，搞好實(shí)現(xiàn)功能不就好了嗎？

可以這樣想一下到了一定的工作年限技術(shù)的廣度深度都有一定的造詣了，你寫(xiě)代碼就這樣了沒(méi)辦法優(yōu)化了，機(jī)器配置也是最好的了，那還能優(yōu)化啥？?底層，我們都知道所有語(yǔ)言到最后要運(yùn)行都是變成機(jī)器語(yǔ)言的，最后歸根究底都是要去跟機(jī)器交互的，那計(jì)算機(jī)的底層是不是最后還是要關(guān)注的東西了！

Redis

Redis是什么？

Redis相當(dāng)于是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，說(shuō)到數(shù)據(jù)庫(kù)，傳統(tǒng)的數(shù)據(jù)庫(kù)都是存在硬盤(pán)中，redis的特點(diǎn)是存在內(nèi)存中，所以讀寫(xiě)速度非常的快，因此redis主要用于緩存業(yè)務(wù)。redis支持事務(wù)，持久化以及多種集群方案。

Tip：redis不負(fù)責(zé)編碼工作，put進(jìn)行什么類型的值，get出去的時(shí)候也就是什么類型的值。之間是有一個(gè)二進(jìn)制安全的

為什么選擇Redis？

我們要根據(jù)它的特點(diǎn)來(lái)論述。高并發(fā)，高性能！

我們先從高性能簡(jiǎn)單介紹一下，因?yàn)槭窃趦?nèi)存中操作所以它的讀寫(xiě)能力非常的快，它可以比其他在磁盤(pán)上操作數(shù)據(jù)庫(kù)有更高的速度與性能。

高并發(fā)主要體現(xiàn)在直接操作內(nèi)存比操作數(shù)據(jù)庫(kù)的磁盤(pán)有著更高的效率與性能，所以它在接受請(qǐng)求的時(shí)候往往可以承受更高的并發(fā)量。從磁盤(pán)讀寫(xiě)數(shù)據(jù)都是有磁盤(pán)IO的，而內(nèi)存的話就不需要這一點(diǎn)！

Memcached是什么？區(qū)別在哪？

memcached是一套分布式的快取系統(tǒng)，跟redis類似，和redis的區(qū)別如下。這里不過(guò)多介紹了，今天的主題是redis。

區(qū)別

1. redis支持五大數(shù)據(jù)類型，Memcached支持的數(shù)據(jù)類型極少一定程度上根本完成不了業(yè)務(wù)需求

2. redis支持事務(wù)

3. memcached沒(méi)有原生的集群模式，需要用戶單獨(dú)編寫(xiě)。redis是支持原生cluster模式。

4. Memcached是多線程，非阻塞IO復(fù)用的網(wǎng)絡(luò)模型；Redis使用單線程的多路 IO 復(fù)用模型。

應(yīng)用場(chǎng)景

Redis的五大數(shù)據(jù)類型應(yīng)用場(chǎng)景都是什么？

hash：因?yàn)樗挠成潢P(guān)系的特性，特別適合存一些存儲(chǔ)對(duì)象。比如用戶詳情，商品詳情，訂單詳情等。

string：是簡(jiǎn)單的key-value結(jié)構(gòu)，value不僅可以是string類型也可以是數(shù)字，比如生活中常見(jiàn)的關(guān)注數(shù)，粉絲數(shù)等等。

list：是一個(gè)鏈表，有序的可重復(fù)存儲(chǔ)。它的應(yīng)用場(chǎng)景非常的多，比如關(guān)注列表，分析列表，消息列表，高性能分頁(yè)（下拉數(shù)據(jù)一直不斷刷新的那種）等。這里需要著重強(qiáng)調(diào)一下list有單鏈表以及雙鏈表。這里的redis list實(shí)現(xiàn)的是雙向鏈表，所以可以支持反向查詢和遍歷。

set：無(wú)序的，不支持重復(fù)存儲(chǔ)。主要通過(guò)交并差集操作實(shí)現(xiàn)一些類似于微博的共同好友，共同粉絲，隨機(jī)事件，抽獎(jiǎng)，選名等功能。

sorted set：比set增加了一個(gè)權(quán)重閾值。也就是參照的意思，第一新增了score分值，rank排名。主要用于一些直播系統(tǒng)中的實(shí)時(shí)排名信息。包括在線用戶列表，禮物排行列表，彈幕消息列表等功能。

Java里完全也可以實(shí)現(xiàn)，為什么非要用Redis來(lái)替代呢？

輕量級(jí)！

數(shù)據(jù)放入的是Redis不在本地CPU，所以不會(huì)影響當(dāng)前的程序。如果放在本地?cái)?shù)據(jù)量到了一定級(jí)別的時(shí)候有可能數(shù)據(jù)量已經(jīng)消耗完了CPU的內(nèi)存，會(huì)超過(guò)本地CPU溢出，所以分離了占用的位置。

過(guò)期策略

Redis過(guò)期是什么

redis可以自己手動(dòng)設(shè)置一些值的過(guò)期時(shí)間，在我們set一個(gè)值的時(shí)候都可以規(guī)定這個(gè)值什么時(shí)候過(guò)期，這點(diǎn)的好處是極大的提高了數(shù)據(jù)的可用性。比如我們的短信驗(yàn)證碼，token登錄信息等功能

Redis的數(shù)據(jù)是按照什么刪除的？

redis數(shù)據(jù)的刪除主要分兩種。第一種是定期刪除，第二種是惰性刪除。

顧名思義。

定期刪除就是每隔一段時(shí)間定期遍歷數(shù)據(jù)采用隨機(jī)刪除的思想（如果不采用隨機(jī)刪除的話那么大的數(shù)據(jù)量是非常影響性能的）。這樣的話極大的影響了CPU的性能。

惰性刪除是指在定期刪除的基礎(chǔ)上因?yàn)椴捎秒S機(jī)刪除的關(guān)系所以會(huì)導(dǎo)致一部分?jǐn)?shù)據(jù)經(jīng)過(guò)定期刪除后依然沒(méi)有被刪除，所以就有了惰性刪除。假如你的過(guò)期key通過(guò)定期刪除沒(méi)有被刪除，那么惰性刪除要做的就是，客戶端如果再一次訪問(wèn)這個(gè)過(guò)期的key，或者系統(tǒng)去查一下這個(gè)key才會(huì)被redis刪除。這就是所謂的惰性刪除。

如果定期刪除漏掉了很多過(guò)期 key，然后你也沒(méi)及時(shí)去查， 也就沒(méi)走惰性刪除，此時(shí)會(huì)怎么樣？如果大量過(guò)期key堆積在內(nèi)存里，導(dǎo)致redis內(nèi)存塊耗盡了。怎么解決這個(gè)問(wèn)題 呢？redis 內(nèi)存淘汰機(jī)制展開(kāi)了。

內(nèi)存淘汰機(jī)制

Redis的數(shù)據(jù)淘汰策略（暫時(shí)簡(jiǎn)單介紹吧后續(xù)會(huì)出一份Redis底層實(shí)現(xiàn)的文章）

1. volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

2. volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選將要過(guò)期的數(shù)據(jù)淘汰

3. volatile-random：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰

4. allkeys-lru：當(dāng)內(nèi)存不足以容納新寫(xiě)入數(shù)據(jù)時(shí)，在鍵空間中，移除最近最少使用的key（這個(gè)是最常用的）.

5. allkeys-random：從數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰

6. no-eviction：禁止驅(qū)逐數(shù)據(jù)，也就是說(shuō)當(dāng)內(nèi)存不足以容納新寫(xiě)入數(shù)據(jù)時(shí)，新寫(xiě)入操作會(huì)報(bào)錯(cuò)。（這個(gè)應(yīng)該沒(méi)人使用吧！）

事務(wù)

概念

Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個(gè)命令，一個(gè)事務(wù)中所有命令都會(huì)被序列化。在事務(wù)執(zhí)行過(guò)程，會(huì)按照順序串行化執(zhí)行隊(duì)列中的命令，其他客戶端提交的命令請(qǐng)求不會(huì)插入到事務(wù)執(zhí)行命令序列中。

總結(jié)說(shuō)：redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令

Redis事務(wù)沒(méi)有隔離級(jí)別的概念

批量操作在發(fā)送 EXEC 命令前被放入隊(duì)列緩存，并不會(huì)被實(shí)際執(zhí)行，也就不存在事務(wù)內(nèi)的查詢要看到事務(wù)里的更新，事務(wù)外查詢不能看到

Redis不保證原子性

Redis中，單條命令是原子性執(zhí)行的，但事務(wù)不保證原子性，且沒(méi)有回滾。事務(wù)中任意命令執(zhí)行失敗，其余的命令仍會(huì)被執(zhí)行

Redis事務(wù)的三個(gè)階段

• 開(kāi)始事務(wù)

• 命令入隊(duì)

• 執(zhí)行事務(wù)

Redis事務(wù)命令操作（本篇文章介紹大概的知識(shí)點(diǎn)，比如常用命令自己搜watch，exec命令找案例，不過(guò)多介紹了）

• watch key1 key2 … : 監(jiān)視一或多個(gè)key,如果在事務(wù)執(zhí)行之前，被監(jiān)視的key被其他命令改動(dòng)，則事務(wù)被打斷 （ 類似樂(lè)觀鎖 ）

• multi : 標(biāo)記一個(gè)事務(wù)塊的開(kāi)始（ queued ）

• exec : 執(zhí)行所有事務(wù)塊的命令 （ 一旦執(zhí)行exec后，之前加的監(jiān)控鎖都會(huì)被取消掉 ）

• discard : 取消事務(wù)，放棄事務(wù)塊中的所有命令

• unwatch : 取消watch對(duì)所有key的監(jiān)控

壓縮表與跳躍表

壓縮表與跳躍表之間的關(guān)系就是 單個(gè)元素過(guò)于龐大時(shí)，轉(zhuǎn)換為跳躍表。簡(jiǎn)單來(lái)說(shuō)，也就是犧牲空間換速度的一種方案。任何一種便捷的技術(shù)都會(huì)有弊端的！

持久性

概念

持久化就是把內(nèi)存的數(shù)據(jù)寫(xiě)到磁盤(pán)中去，防止服務(wù)宕機(jī)了內(nèi)存數(shù)據(jù)丟失。Redis 提供了兩種持久化方式:RDB（默認(rèn)） 和AOF

RDB

RDB也就是快照，快照的作用就是在Redis崩掉的時(shí)候起到了恢復(fù)的作用?？煺帐潜４娈?dāng)前某一個(gè)時(shí)間點(diǎn)范圍的數(shù)據(jù)，每個(gè)小時(shí)保存一次。例如9點(diǎn)整開(kāi)啟一次快照，在9點(diǎn)59的時(shí)候系統(tǒng)崩掉了。那么就損失了59分鐘的數(shù)據(jù)。這種的弊端是性能挺好，就是丟失的數(shù)據(jù)比較多一些。

AOF

AOF是追加文件的方式。AOF實(shí)時(shí)性更好。這種方式默認(rèn)是不開(kāi)啟的。AOF是實(shí)時(shí)的，所以就算丟失數(shù)據(jù)頂多只會(huì)丟失一秒的數(shù)據(jù)

持久性的方案

首先利用RDB快照進(jìn)行整點(diǎn)恢復(fù)。然后再利用AOF進(jìn)行剩余部分的實(shí)時(shí)恢復(fù)。RDB的恢復(fù)速度非常快，AOF恢復(fù)速度雖然慢一點(diǎn)但是恢復(fù)的數(shù)據(jù)量不大因?yàn)樽疃嘀粫?huì)恢復(fù)一個(gè)小時(shí)內(nèi)的數(shù)據(jù)量。

還是舉以上的例子：9點(diǎn)鐘利用RDB進(jìn)行了一次快照保存數(shù)據(jù)，9點(diǎn)59分的時(shí)候來(lái)了一個(gè)原子彈把服務(wù)器炸成灰了。持久化的方案就是利用RDB快照恢復(fù)了大部分的數(shù)據(jù)，但是丟失了59分鐘的數(shù)據(jù)，因?yàn)镽DB是一個(gè)小時(shí)執(zhí)行一次快照所以RDB解決不了。利用AOF恢復(fù)剩下的59分的數(shù)據(jù)不需要利用AOF恢復(fù)整體的數(shù)據(jù)了。

常見(jiàn)問(wèn)題

• 緩存穿透

• 緩存雪崩

• 緩存預(yù)熱

• 緩存降級(jí)

緩存穿透以及解決方案

緩存穿透：一般訪問(wèn)緩存的流程，如果緩存中存在查詢的商品數(shù)據(jù)，那么直接返回。如果緩存中不存在商品數(shù)據(jù)，就要訪問(wèn)數(shù)據(jù)庫(kù)。由于不恰當(dāng)?shù)臉I(yè)務(wù)功能實(shí)現(xiàn)，或者外部惡意攻擊不斷地請(qǐng)求某些不存在的數(shù)據(jù)內(nèi)存，由于緩存中沒(méi)有保存該數(shù)據(jù)，導(dǎo)致所有的請(qǐng)求都會(huì)落到數(shù)據(jù)庫(kù)上，對(duì)數(shù)據(jù)庫(kù)可能帶來(lái)一定的壓力，甚至崩潰。

解決方案：

針對(duì)緩存穿透的情況， 簡(jiǎn)單的對(duì)策就是將不存在的數(shù)據(jù)訪問(wèn)結(jié)果， 也存儲(chǔ)到緩存中，避免緩存訪問(wèn)的穿透。最終不存在商品數(shù)據(jù)的訪問(wèn)結(jié)果也緩存下來(lái)。有效的避免緩存穿透的風(fēng)險(xiǎn)

緩存雪崩以及解決方案

緩存雪崩：

當(dāng)緩存重啟或者大量的緩存在某一時(shí)間段失效，這樣就導(dǎo)致大批流量直接訪問(wèn)數(shù)據(jù)庫(kù)，對(duì) DB 造成壓力， 從而引起 DB 故障，系統(tǒng)崩潰。

舉例來(lái)說(shuō)， 我們?cè)跍?zhǔn)備一項(xiàng)搶購(gòu)的促銷(xiāo)運(yùn)營(yíng)活動(dòng)，活動(dòng)期間將帶來(lái)大量的商品信息、庫(kù)存等相關(guān)信息的查詢。為了避免商品數(shù)據(jù)庫(kù)的壓力，將商品數(shù)據(jù)放入緩存中存儲(chǔ)。不巧的是，搶購(gòu)活動(dòng)期間，大量的熱門(mén)商品緩存同時(shí)失效過(guò)期了，導(dǎo)致很大的查詢流量落到了數(shù)據(jù)庫(kù)之上。對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)造成很大的壓力。

解決方案：

1. 將商品根據(jù)品類熱度分類， 購(gòu)買(mǎi)比較多的類目商品緩存周期長(zhǎng)一些， 購(gòu)買(mǎi)相對(duì)冷門(mén)的類目
   商品，緩存周期短一些；

2. 在設(shè)置商品具體的緩存生效時(shí)間的時(shí)候， 加上一個(gè)隨機(jī)的區(qū)間因子， 比如說(shuō) 5~10 分鐘
   之間來(lái)隨意選擇失效時(shí)間；

3. 提前預(yù)估 DB 能力， 如果緩存掛掉，數(shù)據(jù)庫(kù)仍可以在一定程度上抗住流量的壓力

這三個(gè)策略能夠有效的避免短時(shí)間內(nèi)，大批量的緩存失效的問(wèn)題

緩存預(yù)熱以及解決方案

緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫(kù)，然后再將數(shù)據(jù)緩存的問(wèn)題。用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)。如果不進(jìn)行預(yù)熱， 那么 Redis 初識(shí)狀態(tài)數(shù)據(jù)為空，系統(tǒng)上線初期，對(duì)于高并發(fā)的流量，都會(huì)訪問(wèn)到數(shù)據(jù)庫(kù)中， 對(duì)數(shù)據(jù)庫(kù)造成流量的壓力。如圖所示：

解決方案：

1. 數(shù)據(jù)量不大的時(shí)候，工程啟動(dòng)的時(shí)候進(jìn)行加載緩存動(dòng)作；

2. 數(shù)據(jù)量大的時(shí)候，設(shè)置一個(gè)定時(shí)任務(wù)腳本，進(jìn)行緩存的刷新；

3. 數(shù)據(jù)量太大的時(shí)候，優(yōu)先保證熱點(diǎn)數(shù)據(jù)進(jìn)行提前加載到緩存

緩存降級(jí)以及解決方案

降級(jí)的情況，就是緩存失效或者緩存服務(wù)掛掉的情況下，我們也不去訪問(wèn)數(shù)據(jù)庫(kù)。我們直接訪問(wèn)內(nèi)存部分?jǐn)?shù)據(jù)緩存或者直接返回默認(rèn)數(shù)據(jù)。舉例來(lái)說(shuō)：對(duì)于應(yīng)用的首頁(yè)，一般是訪問(wèn)量非常大的地方，首頁(yè)里面往往包含了部分推薦商品的展示信息。這些推薦商品都會(huì)放到緩存中進(jìn)行存儲(chǔ)，同時(shí)我們?yōu)榱吮苊饩彺娴漠惓Ｇ闆r，對(duì)熱點(diǎn)商品數(shù)據(jù)也存儲(chǔ)到了內(nèi)存中。同時(shí)內(nèi)存中還保留了一些默認(rèn)的商品信息。

降級(jí)一般是有損的操作，所以盡量減少降級(jí)對(duì)于業(yè)務(wù)的影響程度。

集群

作為緩存數(shù)據(jù)庫(kù)，肯定要考慮緩存服務(wù)穩(wěn)定性相關(guān)的保障機(jī)制

持久化機(jī)制就是保證系統(tǒng)崩潰的一個(gè)機(jī)制

內(nèi)存淘汰機(jī)制就是保證系統(tǒng)內(nèi)數(shù)據(jù)是否一直有效的一個(gè)機(jī)制

那么如果單機(jī)數(shù)據(jù)直接掛掉，電腦炸成渣了怎么辦？怎么保證數(shù)據(jù)的備份呢？單點(diǎn)故障！延伸了集群！

Redis集群模式一共有三種

• 主從模式

• 哨兵模式

• cluster模式

解釋一下：

單機(jī)模式下如果數(shù)據(jù)被炸毀，也就是出現(xiàn)了單點(diǎn)故障，可以利用主從復(fù)制方式，進(jìn)行多臺(tái)redis數(shù)據(jù)的全量同步。主從復(fù)制集群主要有三種分別是強(qiáng)一致性，弱一致性，最終一致性。強(qiáng)一致性可以保證redis1與redis2數(shù)據(jù)保證同步，但是真實(shí)的場(chǎng)景中往往影響性能。redis3與redis4無(wú)法保證數(shù)據(jù)必須一致，不出意外的話這種方式既可以解決主從復(fù)制也可以解決性能的問(wèn)題所以這種方式是默認(rèn)的。redis5與redis6利用黑盒最終一致性。

主從復(fù)制

顧名思義，Redis服務(wù)器分為兩類也就是主服務(wù)器(Master)與從數(shù)據(jù)庫(kù)(Slave)。這是為了避免單點(diǎn)故障的數(shù)據(jù)丟失引出的一個(gè)方案。通常的做法就是一臺(tái)服務(wù)器的數(shù)據(jù)復(fù)制多個(gè)副本以部署在不同的服務(wù)器上。即使有一臺(tái)服務(wù)器崩掉了也不至于癱瘓整個(gè)服務(wù)，另外幾臺(tái)服務(wù)器依然可以為系統(tǒng)提供服務(wù)。

Redis 提供了復(fù)制功能?？梢詫?shí)現(xiàn)當(dāng)一臺(tái)數(shù)據(jù)庫(kù)中的數(shù)據(jù)更新后，自動(dòng)將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫(kù)上。

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

1. 一個(gè)主，可以有多個(gè)從，并以非阻塞的方式完成數(shù)據(jù)同步；

2. 從服務(wù)器提供讀服務(wù)，分散主服務(wù)的壓力，實(shí)現(xiàn)讀寫(xiě)分離；

3. 從服務(wù)器之前可以彼此連接和同步請(qǐng)求，減少主服務(wù)同步壓力。

缺點(diǎn)

1. 不具備容錯(cuò)和恢復(fù)功能，主服務(wù)存在單點(diǎn)風(fēng)險(xiǎn)；

2. Redis 的主從復(fù)制采用全量復(fù)制，需要服務(wù)器有足夠的空余內(nèi)存；

3. 主從模式較難支持在線擴(kuò)容

哨兵模式

Redis 提供的 sentinel（哨兵）機(jī)制，通過(guò) sentinel (哨兵)模式啟動(dòng)redis后，自動(dòng)監(jiān)控 主Master/從Slave的運(yùn)行狀態(tài)，基本原理是：心跳機(jī)制 + 投票裁決。

簡(jiǎn)單來(lái)說(shuō)，哨兵的作用就是監(jiān)控 Redis 系統(tǒng)的運(yùn)行狀況。它的功能包括以下兩個(gè)：

1. 監(jiān)控主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)是否正常運(yùn)行；

2. 主數(shù)據(jù)庫(kù)出現(xiàn)故障時(shí)自動(dòng)將從數(shù)據(jù)庫(kù)轉(zhuǎn)換為主數(shù)據(jù)庫(kù)。

哨兵模式主要有下面幾個(gè)內(nèi)容：

1. 監(jiān)控（ Monitoring ）：Sentinel 會(huì)定期檢查主從服務(wù)器是否處于正常工作狀態(tài)。

2. 提醒（ Notification ）：當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)異常時(shí)，Sentinel 可以通過(guò)API 向管理員或者其他應(yīng)用程序發(fā)送通知。

3. 自動(dòng)故障遷移（Automatic failover）：當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)，Sentinel 會(huì)開(kāi)始一次自動(dòng)故障遷移操作，它會(huì)將失效主服務(wù)器的其中一個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器，并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器；當(dāng)客戶端試圖連接失效的主服務(wù)器時(shí)，集群也會(huì)向客戶端返回新主服務(wù)器的地址， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器。

Redis Sentinel 是一個(gè)分布式系統(tǒng)，你可以在一個(gè)架構(gòu)中運(yùn)行多個(gè) Sentinel （哨兵）進(jìn)程（ progress ）

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

1. 哨兵模式主從可以切換，具備基本的故障轉(zhuǎn)移能力；

2. 哨兵模式具備主從模式的所有優(yōu)點(diǎn)。

缺點(diǎn)

1. 哨兵模式也很難支持在線擴(kuò)容操作；

2. 集群的配置信息管理比較復(fù)雜

cluster模式

Redis Cluster 是一種服務(wù)器 Sharding 技術(shù)，采用無(wú)中心結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài),每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接。

Cluster 集群結(jié)構(gòu)特點(diǎn)：

1. Redis Cluster 所有的物理節(jié)點(diǎn)都映射到 [ 0-16383 ] slot 上（不一定均勻分布），Cluster
   負(fù)責(zé)維護(hù)節(jié)點(diǎn)、桶、值之間的關(guān)系；

2. 在 Redis 集群中放置一個(gè) key-value 時(shí)，根據(jù) CRC16(key) mod 16384 的值，從之前
   劃分的 16384 個(gè)桶中選擇一個(gè)；

3. 所有的 Redis 節(jié)點(diǎn)彼此互聯(lián)（PING-PONG 機(jī)制），內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸效率；

4. 超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)到某個(gè)節(jié)點(diǎn)失效時(shí)則判定該節(jié)點(diǎn)失效；

5. 使用端與 Redis 節(jié)點(diǎn)鏈接,不需要中間 proxy 層，直接可以操作，使用端不需要連接集群
   所有節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

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

1. 無(wú)中心架構(gòu)，節(jié)點(diǎn)間數(shù)據(jù)共享，可動(dòng)態(tài)調(diào)整數(shù)據(jù)分布；

2. 節(jié)點(diǎn)可動(dòng)態(tài)添加刪除，擴(kuò)展性比較靈活；

3. 部分節(jié)點(diǎn)異常，不影響整體集群的可用性。

缺點(diǎn)

1. 集群實(shí)現(xiàn)比較復(fù)雜；

2. 批量操作指令（ mget、mset 等）支持有限；

3. 事務(wù)操作支持有限

如何解決并發(fā)？

多實(shí)例的方式

分布式的話又會(huì)遇到哪些問(wèn)題呢？

redis分布式并發(fā)競(jìng)爭(zhēng)key的問(wèn)題

所謂 Redis 的并發(fā)競(jìng)爭(zhēng) Key 的問(wèn)題也就是多個(gè)系統(tǒng)同時(shí)對(duì)一個(gè) key 進(jìn)行操作，但是最后執(zhí)行的順序和我們期望的順序不同，這樣也就導(dǎo)致了結(jié)果的不同！

推薦一種方案：分布式鎖（zookeeper 和 redis 都可以實(shí)現(xiàn)分布式鎖）。（如果不存在 Redis的并發(fā)競(jìng)爭(zhēng) Key 問(wèn)題，不要使用分布式鎖，這樣會(huì)影響性能）

基于zookeeper臨時(shí)有序節(jié)點(diǎn)可以實(shí)現(xiàn)的分布式鎖。大致思想為：每個(gè)客戶端對(duì)某個(gè)方法加鎖時(shí)，在zookeeper上的與該方法對(duì)應(yīng)的指定節(jié)點(diǎn)的目錄下，生成一個(gè)唯一的瞬時(shí)有序節(jié)點(diǎn)。判斷是否獲取鎖的方式很簡(jiǎn)單，只需要判斷有序節(jié)點(diǎn)中序號(hào)最小的一個(gè)。當(dāng)釋放鎖的時(shí)候，只需將這個(gè)瞬時(shí)節(jié)點(diǎn)刪除即可。同時(shí)，其可以避免服務(wù)宕機(jī)導(dǎo)致的鎖無(wú)法釋放，而產(chǎn)生的死鎖問(wèn)題。完成業(yè)務(wù)流程后，刪除對(duì)應(yīng)的子節(jié)點(diǎn)釋放鎖。在實(shí)踐中，當(dāng)然是從以可靠性為主。所以首推Zookeeper。參考：https://www.jianshu.com/p/8bddd381de06

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

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

一般來(lái)說(shuō)，就是如果你的系統(tǒng)不是嚴(yán)格要求緩存+數(shù)據(jù)庫(kù)必須一致性的話，緩存可以稍微的跟數(shù)據(jù)庫(kù)偶爾有不一致的 情況，最好不要做這個(gè)方案，讀請(qǐng)求和寫(xiě)請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣就可以保證一定不會(huì)出現(xiàn)不一致 的情況串行化之后，就會(huì)導(dǎo)致系統(tǒng)的吞吐量會(huì)大幅度的降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。參考https://zhuanlan.zhihu.com/p/63428500

這篇文章的描述是跟馬士兵教育視頻，敖丙，DeepInThought，問(wèn)天 學(xué)習(xí)之后自己優(yōu)化升級(jí)的！感謝這幾位大佬！

知道的越多，不知道的就越多。找準(zhǔn)方向，堅(jiān)持自己的定位！加油向前不斷前行，終會(huì)有柳暗花明的一天！
創(chuàng)作不易，你們的支持就是對(duì)我最大認(rèn)可！
文章將持續(xù)更新，我們下期見(jiàn)！【下期將更新SpringCloud入門(mén) QQ群：1076570504 微信公眾號(hào)搜索【歡少的成長(zhǎng)之路】請(qǐng)多多支持！