我的緩存守護進程應該在哪裏生存？

TL; DR--應該在應用的服務器上（即與nginx和php一起）還是在其自己單獨的ec2實例（如elasticache或定製的ec2實例）上存在用於會話存儲的簡單緩存羣集（使用memcache或redis）？我的緩存守護進程應該在哪裏生存？

我正在使用Amazon OpsWorks來設置我的Web應用程序的基礎結構。我傾向於通過安裝在應用層本身上的memcache實例來實現會話緩存，而不是將其作爲自己的ec2實例。例如：

    [ Load Balancer ] 
       /  |  \ 
[ App Layer 1 ] – [ App Layer 2 ] – [ App Layer 3 ] * /w memcache or redis

與

    [ Load Balancer ] 
      /  |   \ 
[ App Layer 1 ] [ App Layer 2 ] [ App Layer 3 ] 
       \   |  /
       [ Cache Server(s) ] * ElastiCache or custom ec2 /w memcache or redis

哪些優點和缺點嗎？對我來說，後面的解決方案看起來沒有必要，但我可以看到具有非常大的會話緩存的高流量網站可能需要這樣做。

是否有我可能不想在我的nginx/php應用服務器堆棧旁邊運行redis或elasticache的原因？它是否會使自動縮放或監視性能更難以做到？

來源

2014-04-05 mikegreiling

用於ASCII圖表技巧的+1！ –

在應用程序服務器上放置緩存的主要原因是成本問題。這與您的數據庫不在您的Web或應用程序服務器上的相同服務器上的想法是一樣的。

如果你有一個小規模的應用程序，你可能會擠壓在同一臺機器上的所有資源，但隨後你從任何類型的故障中恢復的能力（和「everything fails」），你將丟失數據，您的某些用戶的部分服務已關閉。

一旦您擁有足夠的應用程序服務器，您的緩存集羣成本就會更低。

從架構角度來看，當規模和高可用性很重要時，您應該擁有比更爲複雜的組件更小的組件。

例如，如果您希望將另一個應用程序服務器添加到您的機羣，因爲您擁有更多用戶，添加服務器的速度會更快，因爲您在此服務器上安裝的軟件組件更少，並且服務器已可以爲他們的會話集中存儲以前的用戶提供服務。如果要刪除應用程序服務器（或丟失應用程序服務器），則由該服務器提供服務的用戶可以輕鬆遷移到其他服務器，因爲其會話/狀態存儲在緩存集羣中。

來源

2014-04-06 08:12:52 Guy

第一解決方案的兩個主要缺點是：

你將被迫到會話粘性。
您正在耦合應用程序和緩存的縮放事件。

儘管這些可能不是您的問題，但我一般會盡量避免使用它們，因爲它們會使問題變得更加複雜。

來源

2014-04-06 07:25:44

非常感謝！我選擇了另一個答案，因爲它比較冗長，但這些我們都非常有幫助！ – mikegreiling

Np - 只想添加我的2美分;） –

我的緩存守護進程應該在哪裏生存？

回答

相關問題