2014-02-18 19 views
1

我目前正在開發一個系統,可以大量使用redis來執行一系列Web服務。在Web服務器上的Redis只讀副本

該系統的關鍵標準之一是快速響應。

目前的佈局(忽略負載平衡器等)如下:

  • 2×前端播放框架2.x的服務器
  • 2×作業處理/持久性播放框架2.x的服務器
  • 1×MySQL服務器
  • 2×Redis的服務器,1個主,1個從站

在此設置中,用於redis的2個任務 - 作爲一個沙皮ed緩存並且也作爲消息總線。

目前前端服務器上託管,其在其與Redis的整體進行交互的服務。

前端服務器嘗試平衡跨讀取服務器(目前主站和1個從站)的池讀取,但作爲Redis的,他們需要使他們寫入到主服務器。他們通過在作業處理服務器拾取的隊列上發送消息來處理緩存更新等。

作業處理服務器做阻塞監聽(BLPOP)到Redis的寫入服務器並在必要時處理任務。他們與MySQL有唯一的聯繫。

目前讀副本服務器是一個專用服務器 - 更多那裏能夠切換它,如果當前主無法寫入主。

我在考慮在每臺前端服務器上放置一個redis的只讀副本,這意味着讀取延遲甚至更少,並且寫入(隊列中的消息)會在單獨的連接上被推送到寫入服務器。

如果我需要規模,我可以只用讀奴隸添加更多前端服務器。

這聽起來像一個贏/贏到我,即使寫入服務器暫時斷開了,則前端服務器仍然可以從本地機讀取至少數據和採取相應的行動。

任何人都可以想到爲什麼這可能不是一個好主意?

回答

1

我明白這種方法的優點......但考慮一下:當您需要只擴展一個組件(即FE服務器或Redis)而不是另一個組件時會發生什麼?例如,更多的流量可能意味着你需要更多的應用服務器來處理它,而Redises將會大大減少負載。另一方面,如果你的數據集增長和/或更多的負載放在Redises上 - 你需要擴展這些而不是應用程序。

該設計應該符合您的要求,而且您的建議設置的簡單性具有明確的吸引力(即縮放,只是添加另一個相同的樂高積木),但是從我微薄的體驗 - 任何聽起來太好, 。從長遠來看,即使這現在對你有用,你也可能發現自己陷入了困境。我的建議 - 將您的Redis與您的應用服務器分開,處理和/或圍繞網絡工作,並確保每層都可用並可自行擴展。

+0

感謝您的回覆。是的,我明白你在說什麼了。我猜是因爲這些服務非常特殊,而且服務器上實際上並不是密集型的,所以我有很多備用內存的潛在奢侈品。如果我的redis內存需求膨脹,那麼是的,這是不切實際的。這是一個艱難的,因爲我可以看到兩種方式的好處。 – eazynow

相關問題