服務的無狀態性，即：
=-服務端不保存任何客戶端請求者信息 - 客戶端的每次請求必須具備自描述信息，通過這些信息識別客戶端身份
帶來的好處是什么呢？
• 客戶端請求不依賴服務端的信息，任何多次請求不需要必須訪問到同一台服務
=-服務端的集群和狀態對客戶端透明 =-服務端可以任意的遷移和伸縮 =-減小服務端存儲壓力
什么是有狀態？
有狀態服務，即服務端需要記錄每次會話的客戶端信息，從而識別客戶端身份，根據用戶身份進行請求的處理，典型的設計如 tomcat 中的 session。
例如登錄：用戶登錄后，我們把登錄者的信息保存在服務端 session 中，並且給用戶一個 cookie 值，記錄對應的 session。然后下次請求，用戶攜帶 cookie 值來，我們就能識別到對應 session，從而找到用戶的信息。
缺點是什么？
• 服務端保存大量數據，增加服務端壓力
• 服務端保存用戶狀態，無法進行水平擴展
• 客戶端請求依賴服務端，多次請求必須訪問同一台服務器
狀態化的判斷是指兩個來自相同發起者的請求在服務器端是否具備上下文關系。
如果是狀態化請求，那么服務器端一般都要保存請求的相關信息，每個請求可以默認地使用以前的請求信息。
而無狀態請求則不行，服務器端所能夠處理的過程，他的處理信息必須全部來自於請求所攜帶的信息以及其他服務器端自身所保存的、並且可以被所有請求所使用的公共信息。
無狀態的服務器程序，最著名的就是WEB服務器。
狀態化的服務器有更廣闊的應用范圍，比如MSN、網絡游戲等服務器。他在服務端維護每個連接的狀態信息，服務端在接收到每個連接的發送的請求時，可以從本地存儲的信息來重現上下文關系。
REST架構設計是目前非常火熱的概念，已經成為構建web服務時應該遵循的事實標准。REST約束中有一條很重要的規則是“無狀態”，但“無狀態”是個很抽象的概念，對剛剛接觸的人來講，很難深刻形象的理解。今天在網上看了一篇文章，對於“無狀態”的解釋感覺很容易讓人理解，特把文章中相關內容整理了下。
-
"狀態"的概念是什么
一個Web應用程序協議的“狀態”在通常指的是為兩個相互關聯的用戶交互操作保留的某種公共信息，它們常常被用來存儲工作流或用戶狀態信息等數據。這些信息可以被指定不同的作用域如page，request，session或全局作用域，而存儲他們的責任也同樣可以由Client端或Server端負責。
服務調用過程中有兩種“狀態”：應用狀態(Application State)和資源狀態(Resource State)。
應用狀態指的是與某一特定請求相關的狀態信息，
資源狀態則反映了某一存儲在服務器端資源在某一時刻的特定狀態，該狀態不會因為用戶請求而改變，任何用戶在同一時刻對該資源的請求都會獲得這一狀態的表現（Representation）。
RESTful架構要求服務器端不保有任何與特定HTTP請求相關的資源，所以應用狀態必須由請求方在請求過程中提供。例如session ID可以被認為是一個用來標識某一會話狀態的Key，將其傳遞給服務器端意味着這樣一個請求：“請幫我取出這個狀態信息”，也就是說這個請求假設響應方保有着狀態信息。
由於與某一特定請求相關的狀態屬於應用狀態，而RESTful架構要求任何此類狀態由請求方負責提供，所以傳遞Session ID被認為是unRESTful的做法。
而用戶的身份憑證信息作為一種應用狀態，是被期望由請求方提供的，所以在請求中傳遞用戶的身份憑證信息是符合RESTful架構規范的。 -
為什么要使用無狀態的架構
雖然存儲狀態為企業軟件開發帶來了諸多便利，但是它也給分布式系統的其他方面帶來了許多限制，比如在負載均衡方面，在有狀態的模式下，一個用戶的請求必須被提交到保存有其相關狀態信息的服務器上，否則這些請求可能無法被理解，這也就意味着在此模式下服務器端無法對用戶請求進行自由調度。於此相關的另一個問題是容錯性，倘若保有用戶信息的服務器宕機，那么該用戶最近的所有交互操作將無法被透明地移送至備用服務器上，除非該服務器時刻與主服務器同步全部用戶的狀態信息。此外，由於HTTP本身不是一個有狀態的協議，開發人員必須通過模擬實現狀態的鈍化與激活等。於是為了克服這些不足，無狀態(Statelessness)架構風格屬性受到了廣泛關注。
-
無狀態即各自維護自身的狀態，如會話信息都在客戶端，服務端並不保存狀態信息，那么我們可以說服務端是無狀態的，這個的好處是顯而易見的，無狀態的部分可以很方便的被替換掉（或集群、橫向擴展）而不用狀態重建（或同步），大大提高了可申縮性(scalability);通常J2EE的session被認是不好的設計，大部份J2EE中間件在集群時都需要進行session同步，而Play!並非基於J2EE體系設計的，則沒有該煩惱！
http://www.cnblogs.com/langren1992/p/5536363.html
對服務器程序來說，有兩個基本假設十分重要，究竟服務器是基於狀態請求還是無狀態請求。狀態化的判斷是指兩個來自相同發起者的請求在服務器端是否具備上下文關系。
如果是狀態化請求，那么服務器端一般都要保存請求的相關信息，每個請求可以默認地使用以前的請求信息。
而無狀態請求則不行，服務器端所能夠處理的過程，他的處理信息必須全部來自於請求所攜帶的信息以及其他服務器端自身所保存的、並且可以被所有請求所使用的公共信息。
無狀態的服務器程序，最著名的就是WEB服務器。每次HTTP請求和以前都沒有啥關系，只是獲取目標URI。得到目標內容之后，這次連接就被殺死，沒有任何痕跡。在后來的發展進程中，逐漸在無狀態化的過程中，加入狀態化的信息，比如COOKIE。服務端在響應客戶端的請求的時候，會向客戶端推送一個COOKIE，這個COOKIE記錄服務端上面的一些信息。客戶端在后續的請求中，可以攜帶這個COOKIE，服務端可以根據這個COOKIE判斷這個請求的上下文關系。COOKIE的存在，是無狀態化向狀態化的一個過渡手段，他通過外部擴展手段，COOKIE來維護上下文關系。
狀態化的服務器有更廣闊的應用范圍，比如MSN、網絡游戲等服務器。他在服務端維護每個連接的狀態信息，服務端在接收到每個連接的發送的請求時，可以從本地存儲的信息來重現上下文關系。這樣，客戶端可以很容易使用缺省的信息，服務端也可以很容易地進行狀態管理。比如說，當一個用戶登錄后，服務端可以根據用戶名獲取他的生日等先前的注冊信息；而且在后續的處理中，服務端也很容易找到這個用戶的歷史信息。
狀態化服務器在功能實現方面具有更加強大的優勢，但由於他需要維護大量的信息和狀態，在性能方面要稍遜於無狀態服務器。無狀態服務器在處理簡單服務方面有優勢，但復雜功能方面有很多弊端，比如，用無狀態服務器來實現即時通訊服務器，將會是場惡夢。
這些年，在金融軟件行業發展，對這些行業軟件的開發倍感古怪。原來是一家資訊公司，雖然是行業壟斷地位，但是他們的技術架構倒沒有什么特別之處，只能說很一般。最近在一家交易軟件公司，也是行業壟斷地位，技術架構極其古怪，倒值得說道和探討。
交易軟件的所有架構的理論基礎是基於無狀態假設，主要分為3個層次：
1、虛擬網絡。這是最底層的基於架構，在原有的TCP/IP網絡上構建了一個虛擬的TCP/UDP網絡，這個概念和VPN很像。但也有很多不同。比如虛擬網絡上的節點和節點所接入的實體是按數字化的標識來區別。
2、業務中心。在虛擬網絡上，建立一個業務邏輯中心，管理所有的業務邏輯單元。這個中心本身不處理業務邏輯，而是一個業務邏輯的管理器。
3、業務單元。這個組件是專門實現各個業務邏輯的單元。業務單元本身是建立在業務中心的基礎上。本身具有一定的獨立性，但主要功能還是被綁定在業務中心上。業務中心相當於他的容器。
這3個層次之間消息傳輸都是無狀態的，當客戶端從虛擬網絡上發起一個請求之后，這個請求在整個傳輸過程中，都被認為是攜帶了完整的信息。這樣的處理有個好處，允許傳輸層次進行負載均衡，自由路由，為虛擬網絡的建設提供了很大的彈性。
在業務中心和業務單元之間也是這樣的。他們之間的關系借鑒了MQ的架構。每個消息都是一個完整的、獨立的處理單位。這種架構由於耦合性低，所以實現難度比較低，錯誤發生的概率也改善很多。但從另外一方面來說，要獲取信息的難度卻加大了。比如一個業務邏輯想知道哪些客戶端在線，幾乎是不可能的事情。
由於客戶端之間的狀態是不可知的。所以主動推送需要十分復雜的過程才能實現。不能簡單地做到主動推送，輪詢就成為主要的手段。當輪詢被頻繁地使用之后，系統的實時性就無法保證了。
當然，我在這里不是為了對狀態化和無狀態化的服務器要分個三六九等，實際上他們都有自己適用的范圍。但各個覺得，只要狀態化的服務器的技術風險能夠被克服，應該具備更廣闊的前景，應該是個未來的發展方向。從交易軟件的架構，我還是認為他是個比較成功的應用，畢竟是得到事實的檢驗。但在具體過程中遇到的很多問題，還是和他的無狀態假設有關。感覺這種架構是將錯誤發生的時間和地點給延后了，而不是消滅。
在這種系統中，狀態化依然是最好的架構，但是難度是同樣巨大。
http://blog.csdn.net/cjsycyl/article/details/8692092