redis高可用是什么意思

本篇內容介紹了“redis高可用是什么意思”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

前言

最近在看redis，有一些心得，為了不忘，現在記錄下來。

我嘗試從問題出發，步步遞進，給大家較好的閱讀體驗，具體如下

1. 什么是緩存，為啥要有它

2. 緩存的實現方式-進程內的緩存

3. 緩存的實現方式-進程級別的緩存

4. redis作為一個進程級別的數據庫，優點

5. redis的高可用實現

什么是緩存，為啥要有它

一般我們將數據存儲在數據庫中，對于一些經常查詢的業務，比如用戶訪問某一資源，通常我們會通過查詢數據庫查看用戶是否有這個訪問權限，這樣業務的特點是查詢頻率高，查詢數據庫是比較重的操作，主要的耗時有數據庫本身的查詢耗時和網絡耗時。如果將一些常使用的數據放在程序運行時內存里，隨著程序的啟動，加載數據庫中信息到內存中，這樣就減少了網絡交互和數據庫本身的查詢耗時。

緩存的實現方式-進程內的緩存

這種就是在寫程序時開辟一塊內存，專門當做緩存供程序使用

優點

1. 不需要網絡傳輸。

2. 不需要線程間切換。

3. 緩存更新方便。因為是程序內的內存區域，我需要更新哪個區域，我可以直接定位到內存位置，并更新它。

缺點

1. 拓展性差。還是一個商城的例子，用戶想看自己的購物車，假設我們使用token進行狀態保持，我解析token，抽取用戶id，查看是否具有這個業務操作的權限。如果部署的程序只有一個，完全沒問題。但是為了滿足未來用戶量高速增長，通過nginx橫向拓展程序就可以有問題。假如我們平行的部署兩個程序，用戶來登錄，程序a處理了這個請求，并將該用戶的權限信息，token存在自己的內存區域，當該用戶發起另外一個業務請求時，程序b接受這個請求，程序b拿到用戶的token，抽取用戶信息，查詢自己的內存區域，發現沒有這個用戶信息，就判斷這個用戶沒有訪問權限。

2. 如果是橫向拓展的話，很有可能浪費內存。多個程序都有自己的內存區域，但是內存區域存的東西也是基本一樣的。

緩存的實現方式-進程級別的緩存

優點

1. 節約內存資源。

2. 職責分離更明確

缺點

1. 增加網絡傳輸

2. 增加線程間切換

3. 單點，有風險

redis作為一個進程級別的數據庫，優點

1. 支持高可用部署

2. 為了降低總體網絡傳輸的延遲，提出了一個新思想：

假設我是新街口東方餃子王老板，提供送餐服務，我有2個快遞員，假設我的飯是提前做好的

• 12：00，京師科技大廈小強定了一份餃子，快遞員1去送餐，十分鐘可以送到，再有十分鐘回到飯店

• 12：02，京師科技大廈小紅定了一份餃子，快遞員2去送餐，十分鐘可以送到，再有十分鐘回到飯店

• 12：03，京師科技大廈小花定了一份餃子，沒有快遞員送餐：快遞員1要到12:20才能回來，快遞員2要到12：22才能回來。等待

• 12：04，京師科技大廈特朗普定了5份餃子，沒有快遞員送餐：快遞員1要到12:20才能回來，快遞員2要到12：22才能回來。等待

• 12：05，京師科技大廈克林頓定了5份餃子，沒有快遞員送餐：快遞員1要到12:20才能回來，快遞員2要到12：22才能回來。等待

• 12：20，快遞員1接到小花訂單，去送餐

• 12：22，快遞員2接到特朗普訂單，去送餐

假如特朗普和小強小紅是一個公司的，特朗普心里就不爽了，都是同一時間定的，為啥他們到了，我的還沒到？

那有什么解決方案嗎 ？

1. 減少每趟耗時。比如原來是快遞員騎自行車，現在換成摩托車，原來是摩托車，現在換成汽車，原來汽車，現在換成火箭..

2. 增加快遞員的數量。 原來是2個，我就再招十來個 。

3. 快遞員每趟運送的貨物爭取多一點。比如上述例子，僅僅五分鐘內，連續有京師科技大廈5單訂單，一共13份餃子，假設一個快遞員的后備箱可以裝10分餃子，那在12：05的時候，快遞員1 運送前四個訂單，一共8份，快遞員2運送第五個訂單，一個5分。這樣特朗普就和小強一起吃上飯了。

在計算機中 ，這三種解決方案分別對應的是

1. 減少每趟耗時。往返時間：從發送方發送數據開始，直到發送方收到接收方回復的確認為止。數據傳輸的方式簡單來說是這樣的，先將數據轉換為字節流，然后通過一個裝置（調制解頻器）轉換為電磁波 ，通過網線或者無線電波傳輸，接收方接受到無線電波，將其轉換成字節流，然后在轉換成具體的可供程序使用的數據。是不是腦袋有點大，這個過程的優化可能不是軟件工程師能做的。

2. 吞吐量：單位時間內通過某個網絡的數據量。這個優化可能不是軟件工程師能做的。

3. 對傳輸的數據進行緩沖，降低總體網絡延遲。

第三種思想在很多地方都采用了，比如郵件服務器使用這種思想可以更快的下載新郵件，

redis 也是采用了第三種解決方案

感興趣的同學可以參考官方文檔

https://redis.io/topics/pipelining

redis的高可用實現

高可用的業務需求，當緩存服務因為某些原因不可用時，可以切換到另外一臺機器的的緩存服務上。

可能涉及到的難點

1. 我怎么判斷緩存服務不可用

2. 當不可用的時候，我怎么通知到所有使用緩存服務的客戶端，現在你訪問的這個有問題，你應該訪問另外一個好的

3. 備份的緩存服務存儲的數據怎么和正在使用的緩存服務存儲的數據保持一致

4. 當我down掉的節點可以重新提供使用，怎么能加入到緩存，當做備胎使用

我嘗試著對這幾個問題提出自己的思考

1 我怎么判斷緩存服務不可用

我需要知道每一個客戶端使用緩存服務的情況，假如大家都說緩存有問題，那沒問題，就換一個好的，如果至少有一半的客戶都認為有問題，那這個緩存就有問題。像這樣的事情肯定是誰用誰知道。哈哈

2 當緩存不可用的時候，我怎么通知到所有使用緩存服務的客戶端，現在你訪問的這個有問題，你應該訪問另外一個好的

這個就要在程序部署的時候記錄一下需要使用緩存服務的client，當要切換緩存時，我就逐一通知client就行

3 備份的緩存服務存儲的數據怎么和正在使用的緩存服務存儲的數據保持一致

這個其實很簡單，把訪問緩存的請求copy一份給備份的緩存就行。當然這個操作應該誰來做。如果是我的話，我就在client里來做，我做完一個操作，就把這個操作加到一個緩存隊列中，讓后臺線程處理這個copy操作。

4 當我down掉的節點可以重新提供使用，怎么能加入到緩存，當做備胎使用

這個有兩種方式，一種是down掉的緩存直接通知我，我活了，我想當備胎，你看怎么辦。一種是 我每隔一段的時間對down掉的節點看一下，如果好了，我就將他允許他當備胎。

現在看看redis怎么做的

它提出了一種類型的人:哨兵，他的的職責如下

• 監控。他負責檢查緩存和備胎的健康情況

• 通知。他監控出現異常的時候，可以通知管理員，或者其他程序。

• 自動故障恢復。當緩存不可以時，在備胎請求緩存的時候啟動一個故障恢復的進程，當client使用緩存的時候就會被通知，你要換個備胎來用了。

• 配置提供者。client不能直接的訪問緩存，需要先問一下這哥們我應該訪問那個緩存。

針對上面的四個問題，看看redis是怎么做的

1 我怎么判斷緩存服務不可用

他提出了一個閾值的概念 quorum ，當且僅當這兩個條件滿足時，才能確定一個緩存不可用

• 有幾個哨兵同意當前緩存不可用

• 為了找到一個哨兵啟動故障恢復的進程，哨兵們需要選舉一個領導，由他來執行這個操作。

這個就有點坑爹了，如果是這樣部署的緩存服務

• server001 master soilder01

• server002 replica1 soilder02

閾值設置的是1 ，當soilder02說 master不能使了，ok滿足第一個條件，那第二個條件是找到一個哨兵來啟動故障恢復程序，就剩一個soilder，還怎么選舉，還需要選舉嗎？

當然這種情況可以認為的避免，比如可以將哨兵也可以安排在client里

• server001 master soilder01

• server002 replica1 soilder02

• server003 client1 soilder03

• server004 client2 soilder04

我把閾值設置為 1，就可以解決這個問題。

2 當緩存不可用的時候，我怎么通知到所有使用緩存服務的客戶端，現在你訪問的這個有問題，你應該訪問另外一個好的

客戶端通過哨兵來間接的訪問緩存服務。這樣做的弊端就是增加了一層網絡消耗。本來我直接訪問緩存拿到數據了，現在我需要問一下哨兵，現在的緩存地址是啥，我再根據這個地址訪問緩存服務。

3 備份的緩存服務存儲的數據怎么和正在使用的緩存服務存儲的數據保持一致

當備胎和緩存master連上時，master負責備胎和自己保持一致性。

4 當我down掉的節點可以重新提供使用，怎么能加入到緩存，當做備胎使用

當備胎和緩存master連上時，master負責備胎和自己保持一致性。

“redis高可用是什么意思”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！