? ? ? ? ? ? ? ? ? ? ? ? ? ?Redis哨兵、持久化、主從

?1 為啥Redis那么快

2 單線程的，我們現(xiàn)在服務器都是多核的，那不是很浪費？

3 Redis cluster

4?他們之間是怎么進行數(shù)據(jù)交互的？以及Redis是怎么進行持久化的？Redis數(shù)據(jù)都在內(nèi)存中，一斷電或者重啟不就木有了嘛？

那這兩種機制各自優(yōu)缺點是啥？

5 主從之間的數(shù)據(jù)怎么同步的么？

6?數(shù)據(jù)傳輸?shù)臅r候斷網(wǎng)了或者服務器掛了怎么辦啊？

7 為啥不掃描全部設置了過期時間的key呢？

? ? ? ? ?參考文獻

---

?1 為啥Redis那么快

Redis采用的是基于內(nèi)存的采用的是單進程單線程模型的 KV 數(shù)據(jù)庫，由C語言編寫，官方提供的數(shù)據(jù)是可以達到100000+的QPS（每秒內(nèi)查詢次數(shù)）。

?

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

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

• 采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗；

• 使用多路I/O復用模型，非阻塞IO；

• 使用底層模型不同，它們之間底層實現(xiàn)方式以及與客戶端之間通信的應用協(xié)議不一樣，Redis直接自己構(gòu)建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求；

2 單線程的，我們現(xiàn)在服務器都是多核的，那不是很浪費？

單機開多個Redis實例嘛。

單機會有瓶頸，那你們是怎么解決這個瓶頸的？

用到了集群的部署方式也就是Redis cluster，并且是主從同步讀寫分離，類似Mysql的主從同步，Redis cluster?支撐 N 個?Redis master node，每個master node都可以掛載多個?slave node。

這樣整個?Redis?就可以橫向擴容了。如果你要支撐更大數(shù)據(jù)量的緩存，那就橫向擴容更多的?master?節(jié)點，每個?master?節(jié)點就能存放更多的數(shù)據(jù)了。

3 Redis cluster

在生產(chǎn)環(huán)境中，我們主要還是采用分布式的部署方案，以盡量地避免單點問題，前面我們已經(jīng)講過很多次了，單臺機器故障，在生產(chǎn)環(huán)境中是發(fā)生概率較高的事情，如果因為某臺機器故障而影響了整個系統(tǒng)，那只能說明這個系統(tǒng)非常的不健壯。

一組Redis Cluster是由多個Redis實例組成，官方推薦我們使用6實例，其中3個為主節(jié)點，3個為從結(jié)點。一旦有主節(jié)點發(fā)生故障的時候，Redis Cluster可以選舉出對應的從結(jié)點成為新的主節(jié)點，繼續(xù)對外服務，從而保證服務的高可用性。那么對于客戶端來說，知道對應的key是要路由到哪一個節(jié)點呢？原來，Redis Cluster 把所有的數(shù)據(jù)劃分為16384個不同的槽位，可以根據(jù)機器的性能把不同的槽位分配給不同的Redis實例，對于Redis實例來說，他們只會存儲部門的Redis數(shù)據(jù)，當然，槽的數(shù)據(jù)是可以遷移的，不同的實例之間，可以通過一定的協(xié)議，進行數(shù)據(jù)遷移。

數(shù)據(jù)獲取

客戶端是如何訪問Redis Cluster里面的數(shù)據(jù)呢？首先客戶端需要保存一份Redis Cluster槽相關(guān)的信息，也就是路由表，然后對即將訪問的key進行哈希計算，計算出對應的槽位，然后向?qū)腞edis實例發(fā)起查詢請求。如果訪問的Redis實例中，的確保存著對應槽的數(shù)據(jù)信息，就會進行返回，否則向客戶端返回一個Moved指令，讓客戶端到正確的地址進行獲取。

數(shù)據(jù)遷移

在分布式系統(tǒng)中，衡量一個系統(tǒng)好壞的一項重要指標，系統(tǒng)的擴展性。什么是系統(tǒng)的擴展性呢？就是今天你又10萬個用戶，需要4臺機器進行服務，如果明天的用戶數(shù)量增加到20萬了，是不是只要簡單的增加4臺機器就行，同時又不需要進行復雜的數(shù)據(jù)遷移。Redis Cluster便是如此，當你新增一些實例的時候，只需要將一部分槽位遷移到新的實例即可。在遷移的過程中，客戶端會先去舊的實例上去查詢數(shù)據(jù)，因為遷移正在發(fā)生，如果對應的數(shù)據(jù)還在本機上，那么直接返回，否則返回讓客戶端重定向到新的實例。客戶端先向新的機器發(fā)起ask指令，新實例返回成功后，再一次查詢最終的結(jié)果。

4?他們之間是怎么進行數(shù)據(jù)交互的？以及Redis是怎么進行持久化的？Redis數(shù)據(jù)都在內(nèi)存中，一斷電或者重啟不就木有了嘛？

持久化的話是Redis高可用中比較重要的一個環(huán)節(jié)，因為Redis數(shù)據(jù)在內(nèi)存的特性，持久化必須得有，我了解到的持久化是有兩種方式的。

• RDB：RDB 持久化機制，是對 Redis 中的數(shù)據(jù)執(zhí)行周期性的持久化。
• AOF：AOF 機制對每條寫入命令作為日志，以 append-only 的模式寫入一個日志文件中，因為這個模式是只追加的方式，所以沒有任何磁盤尋址的開銷，所以很快，有點像Mysql中的binlog。

兩種方式都可以把Redis內(nèi)存中的數(shù)據(jù)持久化到磁盤上，然后再將這些數(shù)據(jù)備份到別的地方去，RDB更適合做冷備，AOF更適合做熱備，比如我杭州的某電商公司有這兩個數(shù)據(jù)，我備份一份到我杭州的節(jié)點，再備份一個到上海的，就算發(fā)生無法避免的自然災害，也不會兩個地方都一起掛吧，這災備也就是異地容災，地球毀滅他沒辦法。

tip：兩種機制全部開啟的時候，Redis在重啟的時候會默認使用AOF去重新構(gòu)建數(shù)據(jù)，因為AOF的數(shù)據(jù)是比RDB更完整的。。

那這兩種機制各自優(yōu)缺點是啥？

優(yōu)點：

他會生成多個數(shù)據(jù)文件，每個數(shù)據(jù)文件分別都代表了某一時刻Redis里面的數(shù)據(jù)，這種方式，有沒有覺得很適合做冷備，完整的數(shù)據(jù)運維設置定時任務，定時同步到遠端的服務器，比如阿里的云服務，這樣一旦線上掛了，你想恢復多少分鐘之前的數(shù)據(jù)，就去遠端拷貝一份之前的數(shù)據(jù)就好了。

RDB對Redis的性能影響非常小，是因為在同步數(shù)據(jù)的時候他只是fork了一個子進程去做持久化的，而且他在數(shù)據(jù)恢復的時候速度比AOF來的快。

缺點：

RDB都是快照文件，都是默認五分鐘甚至更久的時間才會生成一次，這意味著你這次同步到下次同步這中間五分鐘的數(shù)據(jù)都很可能全部丟失掉。AOF則最多丟一秒的數(shù)據(jù)，數(shù)據(jù)完整性上高下立判。

還有就是RDB在生成數(shù)據(jù)快照的時候，如果文件很大，客戶端可能會暫停幾毫秒甚至幾秒，你公司在做秒殺的時候他剛好在這個時候fork了一個子進程去生成一個大快照，哦豁，出大問題。

優(yōu)點：

上面提到了，RDB五分鐘一次生成快照，但是AOF是一秒一次去通過一個后臺的線程fsync操作，那最多丟這一秒的數(shù)據(jù)。

AOF在對日志文件進行操作的時候是以append-only的方式去寫的，他只是追加的方式寫數(shù)據(jù)，自然就少了很多磁盤尋址的開銷了，寫入性能驚人，文件也不容易破損。

AOF的日志是通過一個叫非常可讀的方式記錄的，這樣的特性就適合做災難性數(shù)據(jù)誤刪除的緊急恢復了，比如公司的實習生通過flushall清空了所有的數(shù)據(jù)，只要這個時候后臺重寫還沒發(fā)生，你馬上拷貝一份AOF日志文件，把最后一條flushall命令刪了就完事了。

缺點：

一樣的數(shù)據(jù)，AOF文件比RDB還要大。

AOF開啟后，Redis支持寫的QPS會比RDB支持寫的要低，他不是每秒都要去異步刷新一次日志嘛fsync，當然即使這樣性能還是很高，我記得ElasticSearch也是這樣的，異步刷新緩存區(qū)的數(shù)據(jù)去持久化，為啥這么做呢，不直接來一條懟一條呢，那我會告訴你這樣性能可能低到?jīng)]辦法用的，大家可以思考下為啥喲。

?

你單獨用RDB你會丟失很多數(shù)據(jù)，你單獨用AOF，你數(shù)據(jù)恢復沒RDB來的快，真出什么時候第一時間用RDB恢復，然后AOF做數(shù)據(jù)補全，真香！冷備熱備一起上，才是互聯(lián)網(wǎng)時代一個高健壯性系統(tǒng)的王道。

?

假裝思考一會（不要太久，免得以為你真的不會），哦我想起來了，還有哨兵集群sentinel。

哨兵必須用三個實例去保證自己的健壯性的，哨兵+主從并不能保證數(shù)據(jù)不丟失，但是可以保證集群的高可用。

?

為啥必須要三個實例呢？我們先看看兩個哨兵會咋樣。

master宕機了 s1和s2兩個哨兵只要有一個認為你宕機了就切換了，并且會選舉出一個哨兵去執(zhí)行故障，但是這個時候也需要大多數(shù)哨兵都是運行的。

那這樣有啥問題呢？M1宕機了，S1沒掛那其實是OK的，但是整個機器都掛了呢？哨兵就只剩下S2了，沒有哨兵去允許故障轉(zhuǎn)移了，雖然另外一個機器上還有R1，但是故障轉(zhuǎn)移就是不執(zhí)行。

?

經(jīng)典的哨兵集群是這樣的：

?

M1所在的機器掛了，哨兵還有兩個，兩個人一看他不是掛了嘛，那我們就選舉一個出來執(zhí)行故障轉(zhuǎn)移不就好了。

?

• 集群監(jiān)控：負責監(jiān)控 Redis master 和 slave 進程是否正常工作。

• 消息通知：如果某個 Redis 實例有故障，那么哨兵負責發(fā)送消息作為報警通知給管理員。

• 故障轉(zhuǎn)移：如果 master node 掛掉了，會自動轉(zhuǎn)移到 slave node 上。

• 配置中心：如果故障轉(zhuǎn)移發(fā)生了，通知 client 客戶端新的 master 地址。

5 主從之間的數(shù)據(jù)怎么同步的么？

我先說下為啥要用主從這樣的架構(gòu)模式，前面提到了單機QPS是有上限的，而且Redis的特性就是必須支撐讀高并發(fā)的，那你一臺機器又讀又寫，這誰頂?shù)米“?/strong>，不當人啊！但是你讓這個master機器去寫，數(shù)據(jù)同步給別的slave機器，他們都拿去讀，分發(fā)掉大量的請求那是不是好很多，而且擴容的時候還可以輕松實現(xiàn)水平擴容。

你啟動一臺slave 的時候，他會發(fā)送一個psync命令給master ，如果是這個slave第一次連接到master，他會觸發(fā)一個全量復制。master就會啟動一個線程，生成RDB快照，還會把新的寫請求都緩存在內(nèi)存中，RDB文件生成后，master會將這個RDB發(fā)送給slave的，slave拿到之后做的第一件事情就是寫進本地的磁盤，然后加載進內(nèi)存，然后master會把內(nèi)存里面緩存的那些新命名都發(fā)給slave。

?

6?數(shù)據(jù)傳輸?shù)臅r候斷網(wǎng)了或者服務器掛了怎么辦啊？

傳輸過程中有什么網(wǎng)絡問題啥的，會自動重連的，并且連接之后會把缺少的數(shù)據(jù)補上的。

大家需要記得的就是，RDB快照的數(shù)據(jù)生成的時候，緩存區(qū)也必須同時開始接受新請求，不然你舊的數(shù)據(jù)過去了，你在同步期間的增量數(shù)據(jù)咋辦？是吧？

?

Redis的過期策略，是有定期刪除+惰性刪除兩種。

?

定期好理解，默認100ms就隨機抽一些設置了過期時間的key，去檢查是否過期，過期了就刪了。

7 為啥不掃描全部設置了過期時間的key呢？

假如Redis里面所有的key都有過期時間，都掃描一遍？那太恐怖了，而且我們線上基本上也都是會設置一定的過期時間的。全掃描跟你去查數(shù)據(jù)庫不帶where條件不走索引全表掃描一樣，100ms一次，Redis累都累死了。

1 如果一直沒隨機到很多key，里面不就存在大量的無效key了？

2 好問題，惰性刪除，見名知意，惰性嘛，我不主動刪，我懶，我等你來查詢了我看看你過期沒，過期就刪了還不給你返回，沒過期該怎么樣就怎么樣。

3 最后就是如果的如果，定期沒刪，我也沒查詢，那可咋整？

內(nèi)存淘汰機制！

官網(wǎng)上給到的內(nèi)存淘汰機制是以下幾個：

• noeviction:返回錯誤當內(nèi)存限制達到并且客戶端嘗試執(zhí)行會讓更多內(nèi)存被使用的命令（大部分的寫入指令，但DEL和幾個例外）

• allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新添加的數(shù)據(jù)有空間存放。

• volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限于在過期集合的鍵,使得新添加的數(shù)據(jù)有空間存放。

• allkeys-random: 回收隨機的鍵使得新添加的數(shù)據(jù)有空間存放。

• volatile-random: 回收隨機的鍵使得新添加的數(shù)據(jù)有空間存放，但僅限于在過期集合的鍵。

• volatile-ttl: 回收在過期集合的鍵，并且優(yōu)先回收存活時間（TTL）較短的鍵,使得新添加的數(shù)據(jù)有空間存放。

  如果沒有鍵滿足回收的前提條件的話，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。

參考文獻

'https://baijiahao.baidu.com/s?id=1643461909684941861&wfr=spider&for=pc

• Redis中文官網(wǎng)

• 《Redis入門指南(第2版)》

• 《Redis實戰(zhàn)》

• 《Redis設計與實現(xiàn)》

• 《大型網(wǎng)站技術(shù)架構(gòu)——李智慧》

• 《Redis 設計與實現(xiàn)——黃健宏》

• 《Redis 深度歷險——錢文品》

• 《億級流量網(wǎng)站架構(gòu)核心技術(shù)——張開濤》

• 《中華石杉——石杉》

總結(jié)

以上是生活随笔為你收集整理的Redis哨兵、持久化、主从的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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