Redis快取叢集及叢集負載均衡方案設計
快取模組設計
採用分散式快取:
說明:
(1)Web伺服器端只負責呼叫介面獲取/更新資料,不必關心業務資料處理;
(2)介面負責具體的資料處理,包括快取資料的寫入/更新;
(3)快取叢集用於快取伺服器宕機後,資料仍然高可用。
快取寫入規則
使用者訪問業務資料時,查詢快取,如果沒有值,則從資料庫載入redis,並設定過期時間(基於時間過期的更新策略)。
- 針對每一個模組,僅有一塊內容的情況:儲存k/v一條記錄;
- 針對每一個模組,有多塊不同內容的情況:每塊內容儲存一條k/v記錄,同時,”模組key”儲存模組下面所有內容的“內容key”值。其中,”內容key”按照一定規則生成,儘管模組對應的內容有多塊,但是內容key規則只有一條。
以熱門班次模組為例來說明模組有多塊不同內容的情況:熱門班次對應的key是rmbc,對應的內容key規則是rmbc_city_cityId
。熱門班次下面有很多不同的城市,每一個城市屬於熱門班次不同的內容,廣州、上海對應cityId
分別是10、11。在快取廣州熱門班次的時候,會快取一條rmbc_city_10
/…的資料,同時會快取一條rmbc/rmbc_city_10
的資料,在快取上海熱門班次的時候,會快取一條rmbc_city_11
/…的資料,同時,修改rmbc/rmbc_city_10
為rmbc/rmbc_city_10
,rmbc_city_11
。在進行手動實時更新時,首先查詢rmbc的key,知道有rmbc_city_10
rmbc_city_11
對應的資料進行了快取,然後可以具體操作哪條資料進行立即更新。
快取更新規則
時間過期+規則過期:
上面基於時間過期的更新策略,在過期時間內,將一直從快取讀取資料;在過期之後,則需要重新從資料庫載入資料到快取。這種策略的問題是大併發訪問時,容易造成資料庫瞬間高併發讀。解決的辦法是新增“基於規則過期”的更新策略。
新增規則過期的策略之後,當從快取拿到資料後,首先檢查該資料離設定的過期時間是否小於一定的值,如果小於一定值,則讀取資料庫更新快取,進行提前更新,從一定程度上避免了大併發訪問時,資料庫瞬間高併發讀;當從快取讀取不到資料時,從資料庫讀取,並更新快取。
以上更新策略,在快取資料過期後才讀取的時候,仍有可能造成資料庫瞬間高併發讀。
後臺功能設計
後臺功能設計目的
能夠對模組對應的快取資料進行手動選擇性實時更新,實時更新包括:立即實時更新和延遲實時更新。
- 立即實時更新是指:對模組對應的快取資料進行刪除操作,當下一次請求到來時,將從資料庫讀取資料更新快取,達到實時更新的目的。
- 延遲實時更新是指:對模組對應的快取資料重新設定隨機不同的、間隔較短的過期時間,當下一次請求到來時,將不一定從資料庫讀取資料更新快取,在緩急伺服器、資料庫壓力的前提下,達到實時更新的目的。
後臺功能資料表
(1)後臺新增key規則表:ecm_keyrole
(2)key規則資料表各欄位設計目的
- 模組名稱:每一個模組的名稱;
- 模組key:模組在k/v快取對應的key值;value值是模組對應的不同的內容key值;
- 單/多內容:表示模組對應的快取內容有多部分還是一部分
- 內容key規則:模組內容對應的key規則。每個模組有不同內容,但是內容key規則只有一個;
- 預設過期時長:模組快取資料預設的過期時間;
- 預設最大提前更新時間:控制快取資料允許提前更新的最大時長。
(3)key資料表讀取與管理
- 讀取:資料表由於被頻繁使用,所以可以放在快取或者服務全域性變數中;當從快取或全域性變數中不到時,從資料庫讀取,更新快取或全域性變數。這裡解決叢集中迴圈寫伺服器的問題,key規則表放在快取中。
- CRUD:資料表在被修改時,在更新資料庫後,通過呼叫提供的介面更新快取
(4)頻道表 : ecm_channel
(5)頻道模組表:ecm_channel_keyrole
(6)快取叢集表讀取與管理
- 讀取:資料表由於被頻繁使用,所以可以放在快取或者全域性變數中;當從快取或全域性變數中不到時,從資料庫讀取,更新快取或全域性變數。這裡為減少讀取快取次數,提高服務速度,以及方便主機切換,和key規則表一樣放在全域性變數中。
- CRUD:快取叢集表在被修改後,在更新資料庫後,通過服務重啟載入全域性變數
後臺需要實現的功能
(1)對key規則表進行管理;其中,模組key欄位、模組對應的內容key規則欄位為業務字典中值。對key規則表進行增加/修改之後,在更新資料庫之後,需要呼叫提供的介面更新系統全域性變數;對key規則表進行刪除操作時,一方面,需要呼叫提供的介面更新系統全域性變數,另一方面,需要呼叫提供的介面進行快取中快取資料的刪除。
(2)根據key規則表對快取內容進行實時更新:
- 能夠根據頻道ID查詢出屬於該頻道的有哪些模組資料進行了快取,頻道與模組的關係由key規則資料表儲存;其中,頻道與模組是多-多的關係;
- 通過呼叫提供的介面,能夠對模組中快取的所有資料進行實時更新;
- 如果某一模組有多部分內容,如熱門班次有很多城市,不同城市屬於不同內容。後臺還需要能夠根據快取中“模組key”儲存的”內容key”值,進行某一塊內容快取資料的更新。其中,”內容key”在快取時由前臺功能存入“模組key”中。更新多內容中某一塊內容時,可以輸入key值進行更新,也可以全部列出模組中有哪些不同內容,選擇更新。
(3)實時更新應該包括:立即實時更新和延遲實時更新。
(4)設定所有模組的總的預設過期時間。
(5)設定所有模組的總的預設的允許提前更新時長。
(6)對快取叢集表進行管理:對快取叢集表進行修改之後,在更新資料庫之後,通過服務重啟載入全域性變數。
(7)日誌記錄開關功能:通過呼叫介面,進行日誌記錄開關設定,當開關開啟時,介面可以記錄都呼叫了那些介面。
(8)後臺快取手動實時更新實現的效果圖:
(a)對於有些模組,會出現在不同的頁面,為實現手動更新一次達到該模組不同頁面的資料都更新,需要建立頻道與模組關係表。如果不同頁面現實的條數不同,則在快取中快取最多的紀錄。
(b)模組有單內容或者多內容,由key規則表的“單/多內容”欄位進行控制。
快取叢集
主從複製:
宕機處理:
兩種高可用性叢集方案:
- 主-主(Active-Active)工作方式:(HAProxy)
最常用的叢集模型,它提供了高可用性,並且在只有一個節點時也能提供可以接受的效能,該模型允許最大程度的利用硬體資源。每個節點都通過網路對客戶機提供資源,每個節點的容量被定義好,使得效能達到最優,並且每個節點都可以在故障轉移時臨時接管另一個節點的工作。所有的服務在故障轉移後仍保持可用,但是效能通常都會下降。
這種模式的最大優點是不會有伺服器的“閒置”,兩臺伺服器在正常情況下都在工作。但如果有故障發生導致切換,應用將放在同一臺伺服器上執行,由於伺服器的處理能力有可能不能同時滿足資料庫和應用程式的峰值要求,這將會出現處理能力不夠的情況,降低業務響應水平。 - 主-從(Active-Standby)工作方式(Keepalived)
是HA中最簡單的一種,為了提供最大的可用性,以及對效能最小的影響,主-從工作方式需要一個在正常工作時處於備用狀態的節點,主節點處理客戶機的請求,而備用節點處於空閒狀態,當主節點出現故障時,備用節點會接管主節點的工作,繼續為客戶機提供服務,並且不會有任何效能上影響。 - 如果是做Failover而非負載均衡的話,Keepalived的效率肯定是超過HAProxy的
獎池規則實現的快取叢集方案
負載均衡需求設計
(a)對叢集中redis節點進行負載均衡,能夠隨機訪問叢集中的任意正常節點;
(b)節點發生故障時,能夠自動撤銷節點;
(c)節點恢復後,能夠自動新增節點;
(d)能夠記錄叢集中每個節點的執行引數、訪問量;
(e)快取資料持久化。
叢集概要設計
快取叢集分組
(1)不同的服務可以用不同的快取叢集,也可以使用相同的快取叢集;應用伺服器根據需要,篩選出所需的redis節點;
(2)快取節點變化,或者節點的訪問權重發生變化,各應用伺服器需要重啟;
(3)同一叢集中權重之和等於100。
二維表
(1)二維表格式
(2)二維表維護
(a)系統在啟動時根據節點權重計算出隨機數區間,隨機數區間在1~100;
(b)在訪問快取節點之前,產生隨機數r,(1<=r<=100);
(c)隨機數r在哪個節點的隨機數區間,則首先訪問該快取節點,此處假設首先訪問17節點;
(d)訪問17節點,如果17故障,將17節點的有效標記設定為N,隨機數區間置零,進行(e)步驟,否則進行(f)步驟;
(e)根據正常節點權重,重新生成各自的隨機數區間,區間範圍仍為1~100,之後進行(c)步驟;
(f)從17節點取到快取資料,則直接返回,否則從下一個快取節點獲取。從下一個節點獲取資料的迴圈次數不超過預設的某一值;
(g)定時器每段時間主動檢測每個節點的健康狀況,進行故障節點的撤銷、故障恢復之後節點的恢復。
定時器
定時器每段時間執行一次,執行時:
(1)記錄日誌,日誌內容包括:叢集中每個節點當前的有效標記、訪問區間、累計訪問次數;
(2)當某一節點累計訪問次數達到預設最大值時,所有節點訪問次數都設為預設最小值;
(3)對二維表進行主動維護。
快取資料持久化
配置redis快取資料持久化引數
快取系統流程圖
快取系統評價
快取系統評價從下面三個方面進行綜合考慮:
(1)速度;
(2)及時性;
(3)命中率。