您好,登錄后才能下訂單哦!
這篇文章主要介紹“Redis分布式緩存的作用是什么”,在日常操作中,相信很多人在Redis分布式緩存的作用是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Redis分布式緩存的作用是什么”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
主從切換技術的方法是:當主服務器宕機后,需要手動把一臺從服務器切換為主服務器,這就需要人工干預,費事費力,還會造成一段時間內服務不可用。這不是一種推薦的方式,更多時候,我們優先考慮哨兵模式。
哨兵模式是一種特殊的模式,首先Redis提供了哨兵的命令,哨兵是一個獨立的進程,作為進程,它會獨立運行。其原理是哨兵通過發送命令,等待Redis服務器響應,從而監控運行的多個Redis實例。
這里的哨兵有兩個作用
通過發送命令,讓Redis服務器返回監控其運行狀態,包括主服務器和從服務器。
當哨兵監測到master宕機,會自動將slave切換成master,然后通過發布訂閱模式通知其他的從服務器,修改配置文件,讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控,可能會出現問題,為此,我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控,這樣就形成了多哨兵模式。
用文字描述一下故障切換(failover)的過程。假設主服務器宕機,哨兵1先檢測到這個結果,系統并不會馬上進行failover過程,僅僅是哨兵1主觀的認為主服務器不可用,這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用,并且數量達到一定值時,那么哨兵之間就會進行一次投票,投票的結果由一個哨兵發起,進行failover操作。切換成功后,就會通過發布訂閱模式,讓各個哨兵把自己監控的從服務器實現切換主機,這個過程稱為客觀下線。這樣對于客戶端而言,一切都是透明的。
sentinel down-after-milliseconds配置項只是一個哨兵在超過規定時間依舊沒有得到響應后,會自己認為主機不可用。對于其他哨兵而言,并不是這樣認為。哨兵會記錄這個消息,當擁有認為主觀下線的哨兵達到sentinel monitor所配置的數量時,就會發起一次投票,進行failover,此時哨兵會重寫Redis的哨兵配置文件,以適應新場景的需要。
1、所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬。
2、節點的fail是通過集群中超過半數的節點檢測失效時才生效。
3、客戶端與redis節點直連,不需要中間proxy層。客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可。
4、redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->value Redis 集群中內置了 16384 個哈希槽,當需要在 Redis 集群中放置一個 key-value 時,redis 先對 key 使用 crc16 算法算出一個結果,然后把結果對 16384 求余數,這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽,redis 會根據節點數量大致均等的將哈希槽映射到不同的節點。一個節點對應一臺redis服務器。16384個哈希槽最大可以對應16384臺redis服務器。
投票過程是集群中所有master參與,如果半數以上master節點與master節點通信超時(cluster-node-timeout),認為當前master節點掛掉。
什么時候整個集群不可用(cluster_state:fail)?
A:如果集群任意master掛掉,且當前master沒有slave.集群進入fail狀態,也可以理解成集群的slot映射[0-16383]不完整時進入fail狀態. ps : redis-3.0.0.rc1加入cluster-require-full-coverage參數,默認關閉,打開集群兼容部分失敗。
B:如果集群超過半數以上master掛掉,無論是否有slave,集群進入fail狀態。
到此,關于“Redis分布式緩存的作用是什么”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。