認真考慮如何存儲會話數據可以確保系統能夠持續擴展。許多Web服務器或語言都提供了簡單的基于服務器的會話管理方法，但這些方法通常有一些問題，例如把用戶關聯到了特定的服務器。實現分布式緩存，就可以在系統中存放會話數據，使系統能夠持續擴展。
在你得出需要在應用或系統中維護狀態，以及確定不能把狀態存放在最終用戶的瀏覽器上的結論之前，我們希望你花時間認真考慮一下推薦的流程。你應該為此決定感到難過，為自己不能想辦法開發出無狀態的系統或者不能讓最終用戶維護狀態而感到羞愧。
當然，這是在開玩笑，因為我們已經承認，的確有些系統必須維護狀態，即便是很少量的狀態，而且這些狀態最好是在服務、應用或產的基礎設施中維護。考慮到這一點，我們來討論幾個在應用中維護狀態的原則。
第一，也是最重要的，遠離那些要求關聯到一個應用或Web服務器的有狀態系統。這種實現的可用性比那些可以遠程訪問任何服務器上的狀態的實現低。如果關聯的服務器死機了，那么這臺服務器上的所有會話信息(包括狀態)都會失效，相關的客戶(很可能是幾千個)就需要重復他們的操作。即使把數據存放在了本地或網絡存儲上，用戶也需要在另一臺服務器上從頭來過，而上且這期間還會有服務中斷。
第二，不要使用狀態或會話復制服務，如某些應用服務器或第三方集群服務器上的服務。如本章前面所述，這樣的系統不能很好地擴展，因為對會話的修改需要傳播到很多結點上。因此，選擇這種類類型的實現，我們就要關注為了擴展系統需要使用多少內存。
第三，在選擇會話或狀態緩存或持久引時，要選擇不執行真正處理的服務器上的緩存。雖然這有點挑剔，但的確有助于提高可用性，因為當你丟失了一臺服務器時，只會丟失與之相關的緩存，或者只會丟失其上運行的服務，而不會同時丟失兩者。創建一個緩存(或持續)層，也使得我們可以只基于緩存訪問就能進行擴展，而不必再依靠應用服務和內部及遠程的緩存服務了。
采用分布式會話/狀態緩存不要做哪些事：
下面列出了實現緩存管理會話或狀態時要避免的三種方法口不要實現要求關聯到服務器的系統。
不要使用狀態或會話復制，在不同的系統中創建重復的數據。
不要把緩存放在執行操作的系統上(這并不是說不應該有本地應用緩存，只是說最好把會話信息放在自己的服務器層上)。
如果你遵守不要做哪些事情的原則，那么選擇需要做哪些事情就容易多了。對于這些題，找們看不可知論的態度，因此，我們更關心的是設計，而不是實現細節，如應該采用哪種開源的緩存或數據庫解決方案等。我們有一個強烈的感覺，你幾乎不需要自己開發緩存方案。有了那么多分布式對象緩存選擇，從memcached到開源的或第三方的數據庫，如果誰還需要為存放會話信息而實現自己的緩存方案，會顯得很荒謬可笑。
這就帶來了問題，應該用什么實現緩存呢?對我們來說，這個問題實際上是在可靠性和持久性與成本之間進行衡量。如果你期望把會話或狀態信息保存一段時間，如購物車，那么可能會決定采用具有長期可持久性的解決方案存放部分或所有的會話信息。在我們見過的許多實例中，都是采用數據庫來實現的。但是，采用數據庫顯然會使每一事務處理的成本大于簡單的解決方案，如非持久性的分布式對象緩存。
如果你不需要持久性，就可以從眾多的對象緩存中選擇一種。關于對象緩存及其用法的討論。在有些情況下，你可能兩者都會選擇，即數據庫的持久性和數據庫前端的緩存的低成本性。這樣的實現，既具有數據庫的持久性，也可以通過數據庫前端的緩存實現高成本效益的事務處理擴展。
關于分布式會話狀態緩存的考慮因素
下面是三種常見的分布式緩存的實現方法及其優缺點。
只用數據庫來實現成本最高，但所有數據都是持久性的，在分布式環境中可以將更新和讀操作之間的沖突處理得非常好。
非持久性的分布式對象緩存比較快，成本相對較低，但出出故障后，不能恢復數據，對于用戶訪問間隔時間較長的情況不適用。
有的為網站建設，由數掂庫提供持久性，由緩存提供高性價比的擴展性，很適合需要持久性又想成本低的情況。
本文地址：http://m.123beaconmarketing.com//article/3517.html
