一家大型電子商務網站正在考慮將會話緩存從共享緩存切換到專用緩存。使用哪個專用緩存配置?
它通常是在中型服務器(5-6)運行......在繁忙的時候,它的運行在20級中的服務器。在非常繁忙的時候,它是不是不合理的具有每秒2000+的請求到現場
共處一處緩存不夠好這裏還是必須緩存在奉獻工作者角色?
此外,是否必須爲會話數據啓用高可用性?該網站依靠會話數據提供良好的用戶體驗。但緩存仍保持爲Azure的Blob存儲,所以我不知道我完全獲得高可用性選項
一家大型電子商務網站正在考慮將會話緩存從共享緩存切換到專用緩存。使用哪個專用緩存配置?
它通常是在中型服務器(5-6)運行......在繁忙的時候,它的運行在20級中的服務器。在非常繁忙的時候,它是不是不合理的具有每秒2000+的請求到現場
共處一處緩存不夠好這裏還是必須緩存在奉獻工作者角色?
此外,是否必須爲會話數據啓用高可用性?該網站依靠會話數據提供良好的用戶體驗。但緩存仍保持爲Azure的Blob存儲,所以我不知道我完全獲得高可用性選項
使用專用的角色取決於你想要多少角色運行,以及是否不內存使用情況的網絡角色決定他們是否擴展。例如,如果您的Web角色總是推動內存使用,並且它是內存,而不是CPU的擴展觸發器 - 那麼考慮爲緩存使用專用角色,因爲您的Web角色可以處理更長的負載。如果您的Web角色是cpu密集型的,那麼將每個角色的內存專用於緩存可能是首選。您還需要考慮如果以專用角色運行,您需要多個角色來處理負載和可用性,因此即使在非繁忙時間,您至少也會有三個角色運行緩存(但可能會減少Web角色) 。如果您進行大量部署或縮小規模,您可能還想使用專用緩存 - 故意頻繁關閉角色。在協同定位的作用緩存
一個考慮是,如果你有粘性會話的等待時間會比較低,因爲該項目是在同一臺機器上。不幸的是,Azure負載平衡器是輪循機制,並且根本不粘,因此會話回到同一臺機器的機率很低(5個角色的1/5)。這意味着大部分時間緩存項目將從羣集中的其他角色獲取,因此共存時間延遲益處會丟失。
緩存是分佈式和內存中的 - 沒有我知道的blob存儲(除了'集羣的運行時狀態' - 不管是什麼,加載到緩存中的項目可用於集羣中的其他機器從存儲在內存中的機器開始(從機器B讀取到機器A不會將其存儲在機器A上 - 請參閱下面的註釋)。緩存項目始終僅在內存中,緩存大小受限於可用內存
高可用性選項將項目複製到單獨的機器(不是存儲器),所以如果一臺機器出現故障,仍然有一個副本存在,高可用性也會使用更多的內存,因爲項目使用內存兩個不同的地方,如果您的電子商務應用程序出現故障的可能性可能很低一個項目不會被緩存(通過失敗或失效),它可能會從持久數據重建。例如,如果您將購物籃放在緩存中而不是堅持存儲,那麼如果角色能夠回收,您不希望它丟失 - 在這種情況下,高可用性可能是最佳選擇。
很好的回答@SimonMunro但是根據我的經驗,Azure Co-located Cache不適合生產。我們的負載測試告訴我們,當服務器被回收時,緩存需要很長時間才能恢復。我們通過從我們的數據庫獲取數據來對此進行編碼,但是由於數據庫的壓力,我們的站點停滯不前。這不僅發生在節點被回收時;而且如果您擴展和縮減您的雲服務;甚至當你進行VIP交換時。
我們已經進行使用Azure的專用高速緩存相同的測試,並發現它處理的高速緩存輔助角色很少回收到該網站的性能沒有影響的情況。如果您希望自己的網站執行任務,那麼我建議在所有情況下都使用Azure專用緩存。
不錯的一個西蒙。關於「我不確定從機器B讀取到機器A是否也將它存儲在機器A中」的問題 - 我不認爲在緩存服務器端實現中有任何東西根據使用情況移動對象。取決於實現方式,人們可能希望在客戶端啓用本地緩存,但對於緩存客戶端通常是暫時的Web應用程序,這可能不會有好處 - http://msdn.microsoft.com/zh-cn/library/ ee790983.aspx – 2013-02-13 08:38:53
謝謝你清理Yossi。據此編輯。 – 2013-02-13 08:59:14