網絡農業/園林常見？我應該爲我設計我的網站嗎？

Question

我正在運行ASP.NET網站，服務器既讀寫數據到數據庫，也將一些經常訪問的數據作爲緩存直接存儲在進程內存中。當新的請求進來時，它們將在寫入數據庫之前根據緩存中的數據進行處理。

我的託管服務提供商突然決定將他們的服務器放在負載平衡器下。這意味着我的緩存系統會隨着幾臺服務器隨機處理請求而進入香蕉。所以我必須重寫我的應用程序的一大塊只是爲了得到更差的性能，因爲我現在必須查詢數據庫，而不是在內存變量檢查中快速閃電。

首先，我實在看不出分配IIS服務器上的負載在我的經驗DB查詢點是最常見的瓶頸，現在DB必須採取更加敲打。其次，看起來這些事情需要仔細的規劃，而不僅僅是託管服務提供商爲所有客戶設置的東西，並期望所有的應用程序都是爲了適應他們而編寫的。

這些事情是常見的還是我愚蠢地使用進程內存作爲緩存在第一位？

我應該開始尋找一個新的託管服務提供商嗎？或者我可以期待網絡農業早晚到達嗎？我是否應該考慮將此類轉換考慮在我編寫的所有未來應用程序中，並完全避免進程緩存和類似設計？

（請不要想使之成爲一個養殖VS不耕戰，我只是想知道，如果它是很常見的，我有一個發展的時候記住它這一點。）

Answer 1

我肯定更的開發人員，而不是網絡/部署專家。所以，雖然我對這些概念有一個相當好的總體理解（以及一些有陷阱/限制的第一手經驗），但我會依靠其他SO'ers更徹底地審覈我的意見。有了這樣的警告...

首先要注意的是：「網絡農場」不同於「網絡花園」。 Web場通常是一系列（物理或虛擬）機器，通常每個機器都有一個唯一的IP地址，位於某種負載平衡器之後。大多數負載均衡器支持會話親和性，這意味着給定用戶在第一次訪問該站點時將獲得一臺隨機機器，但每次後續命中時都會獲得同一臺機器。因此，您的內存中狀態管理應該仍然可以正常工作，並且會話關聯會使給定會話在其整個生命週期中使用相同的應用程序緩存的可能性很大。

我的理解是一個特定於IIS的「網絡園」，實質上是在同一臺機器上並行運行的Web服務器的「多個實例」。它的作用與Web場相同（支持更多的併發連接）。但是，據我所知，它不支持任何類型的會話關聯。這意味着每個請求都可能在不同的邏輯應用程序中結束，因此每個請求都可能與不同的應用程序緩存一起工作。這也意味着您無法使用進程內會話處理 - 您必須轉到ASP會話狀態服務或SQL支持的會話配置。當我的客戶轉移到網絡花園模式時，那些大事就讓我受不了。

「10首先，我並沒有真正看到在iis服務器上分配負載的點，因爲在我的經驗中，數據庫查詢通常是瓶頸」。 IIS具有有限數量的可用工作線程（可配置，但仍然有限），因此只能提供有限數量的同時連接。即使每個請求都是相當快速的操作，但在繁忙的網站上，有限的上限可能會導致用戶體驗變慢。 Web農場/花園增加了同時發生的請求數量，即使它不能很好地解決CPU負載平衡問題。

「這些事情是常見的還是我愚蠢地使用進程內存作爲緩存的第一位？」「這不是一個真正的」或「問題。是的，根據我的經驗，網絡農場非常普遍（網絡花園不那麼重要，但這可能只是我一起工作的客戶）。無論如何，使用內存緩存沒有任何問題 - 它們是ASP.NET的一個組成部分。當然，有很多方法可以錯誤地使用它們並導致你自己的問題 - 但這是一個更大的討論，並不是真正具體到你的系統是否將部署在Web場上。

在我看來，你應該設計你的系統假設：

• 他們將不得不在一個Web農場/花園運行
• ，你將有會話的親和性
• 你不會有應用程序 - level-cache-affinity

這當然不是分佈式部署的詳盡指南。但我希望它能讓你更瞭解一些農場/花園景觀。