雲計算因其軟體上的按需付費模式而大獲成功，它創造了一種伸縮性模型：
你可以把這種概念擴充套件到整個平台成本上——應用程式伺服器，資料庫和應用。
關於伸縮性的最重要的一點就是——根據負載的情況，白天給公司提供服務的9臺機器在夜間自動縮減到1臺。而這一台之外的其它8臺機器開始給其它公司提供服務。雲計算的這種能夠允許兩個租戶（或更多）共享業務處理能力的特性就叫做過程共享的多重租賃。
假設個場景，就說白天時間有1000個使用者分布在10臺機器上，每台機器大概服務100個使用者。在乙個有狀態的系統結構中，每台機器都只為在本機登 錄並產生了會話(session)的那100個使用者服務。這個由http負載均衡來實現，叫做會話粘連(session stickiness)。
解決這個問題的乙個方法就是把10臺機器的所有會話狀態都複製到一起。這樣一來，任何一台機器都可以為這些使用者服務。但每台機器就會用掉10倍的內 存來保留所有使用者的會話狀態。這些會降低伺服器的可用性，因為一旦有更多的使用者使用時，集群中就需要加入更多的伺服器。當你共享多重租賃的應用中的租戶突 然暴增時，你就沒法應付了。
在無狀態的應用中，你可以在任何乙個地方執行使用者的請求——會話粘連(session stickness)不再是個問題。當使用者從1000減到100後，你可以立即釋放9臺伺服器，調給其它公司使用，只用1台為這100個使用者服務。.
這聽起來很簡單。而實際操作起來卻不是那麼容易。所有的應用都需要狀態。如果應用伺服器不去處理這些狀態，你就必須想其它的辦法。資料庫就是乙個明 顯的問題。當前的資料庫已經在擴充套件問題上遇到了足夠的麻煩了，再加上狀態管理，那是絕對不可行的。所以nosql才要「分布式」儲存。
在paas服務商中你會看到這是一種常見的架構模式：
microsoft azure – web角色 + azure儲存/sql
當然了，還有我們公司 – orangescape，它是執行在gae/amazon ec2 之上的。
我估計vmforce也是這樣的 – spring stateless session beans + force.com db
那就都雲計算吧！有狀態的應用+sql資料庫已成昨日黃花了。(抱歉！實在忍不住。)
會話Bean中的有無狀態，
無狀態就是說有被很多使用者使用，前乙個使用者設定的值會很容易被後乙個使用者所更改，所以無法維護乙個使用者所設定的 值，所以稱之為無狀態，有狀態就是指這個bean例項只被乙個使用者所使用所以可以保持乙個使用者所設定的值，所以稱之 為有狀態的。無狀態使用的是例項池來管理bean 有狀態使用的是啟用管理。...
local,remote區別,有狀態與無狀態區別
無狀態bean不會 專門 儲存客戶端的狀態 需要強調 專門 是因為無狀態會話bean也會有成員變數，有成員變數就可以儲存狀態，但它不會專門為特定的客戶端儲存狀態。有狀態會話bean會儲存客戶端的狀態 對於有狀態會話bean來說，只要有客戶端傳送對有狀態會話bean的訪問，伺服器都會建立乙個會話bea...
單例與多例 無狀態與有狀態
單例 某個類系統範圍內只有乙個例項 多例 某個類在系統範圍內同時有多個例項 無狀態類 類中沒有狀態資訊，一般是無成員變數或成員變數的值是不變的。有狀態類 類中有狀態資訊，一般表現成員變數的值可變，在某一時該被呼叫而改變狀態，之後再呼叫時獲取其正確的狀態。有狀態類的例項 一般是多例的，用於儲存多個相同...