那天,我被拉入一個Redis群聊···
我是Redis,一個叫Antirez的男人把我帶到了這個世界上。
那天,Redis基友群裡,許久未見的大白髮來了一條訊息···


於是,大白拉了一個新的群

以後的日子中,我們們哥仨相互配合,日常工作中最多的就是資料同步了

如果主節點有資料寫入、刪除、修改命令,也會把這些命令挨個通知到從節點,我們把這叫做命令傳播。

透過這樣的方式,我們主節點與從節點之間資料就能保持同步了~
有一次,我不小心掉線了~



我們用上了新的資料同步策略,效率高了不少,就算偶爾掉個線,也能很快把缺失的資料給補上。
就這樣過了一段時間···


新添了人手,我們準備大幹一場!
為了及時獲得和更新主從節點的資訊,我們們哨兵每隔十秒鐘就要用INFO命令去問候一下主節點,主節點會告訴我他有哪些從節點

為了更加及時知道大家是否掉線,我們們哨兵每隔一秒都要用PING命令問候一下群裡的各個小夥伴:


如果在設定的時間裡沒有收到回覆,我就知道這傢伙多半是跪了,就該啟動故障轉移了
不過這只是我的主觀意見,光我一個人說了不算,為了防止誤判,我還得去管理員小群裡徵求一下大家的意見:




接下來,我們們就開始了第一次選舉。



經過一番努力,我終於完成了故障轉移,現在R2是主節點了。
不過沒過多久,R1又回來了:

以上就是我們的日常工作了,透過我們們幾個小夥伴的齊心協力,構成了一個高可用的快取服務,MySQL大哥再也不敢小瞧我們了。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024924/viewspace-2927355/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 破玩意 | Redis 為什麼那麼快
- 首長,Redis效能最佳化十三條軍規立好了,請過目~
- redis叢集之分片叢集的原理和常用代理環境部署
- 超全面Redis分散式高可用方案:哨兵機制
- Springboot 整合 SpringCache 使用 Redis 作為快取
- Redis奪命十二問,你能扛到第幾問?
- 當 Redis 發生高延遲時,到底發生了什麼
- 詳解 Redis 中 big keys 發現和解決
- 93.7% 的程式設計師!竟然都不知道 Redis 為什麼預設16個資料庫?
- redis cluster 故障後,主從位於不同節點的修復。
- redis cluster 故障後,主從位於相同節點的修復(丟失了部分資料)
- redis 備份和恢復
- Redis作者的公開信:開源維護者的掙扎和無奈
- 為什麼RedisCluster會設計成16384個槽呢?
- Redis功能強大,那也頂不住被濫用啊!
- Redis使用不當導致應用卡死
- Redis的概述
- kestrel網路程式設計--開發redis伺服器