記錄一次有關redis緩存服務器掛掉的生產故障
就在上個星期,生產環境,由於redis主機掛掉,業務受阻差不多30分鐘,導致甲方損失差不多300萬,甲方一天的收入大概一個億左右。
後來回顧發生此故障的原因是,雖然生產環境redis集羣配置的是主從模式,並且每個主(master)節點都有3個 從(slave)部署在不同的服務器上,但是這只是解決了讀寫分離和數據備份的問題,並沒有保障redis緩存集羣的高可用性,在主從模式下,主節點故障,集羣則無法進行工作,從節點升主節點需要人工手動干預!也就是無法在redis主節點掛掉以後,不能進行主從切換和選舉!
後來在平臺組的介入下,我們將生產環境的redis集羣做了高可用的方案,redis主從模式+Sentinel(哨兵)-架構圖如下:
Sentinel 哨兵是 redis 官方提供的高可用方案,可以用它來監控多個 Redis 服務實例的運行情況。Redis Sentinel 是一個運行在特殊模式下的 Redis 服務器。Redis Sentinel 是在多個Sentinel 進程環境下互相協作工作的。Sentinel 系統有三個主要任務:
監控:Sentinel 不斷的檢查主服務和從服務器是否按照預期正常工作。
提醒:被監控的 Redis 出現問題時,Sentinel 會通知管理員或其他應用程序。
自動故障轉移:監控的主 Redis 不能正常工作,Sentinel 會開始進行故障遷移操作。將一個從服務器升級新的主服務器。讓其他從服務器掛到新的主服務器。同時向客戶端提供新的主服務器地址。
如果當初在架構設計的時候,就採用主從模式+哨兵的高可用方案,可能就不會出現上個星期的生產事故!被動的等到出了問題時候補救的方式,遠遠不如主動的思考目前我們當下所採用的的架構設計是不是存在某些隱患!防範於未然纔是最重要的!