服務端不儲存任何客戶端請求者資訊，客戶端的每次請求必須具備自述資訊，通過這些資訊識別客戶端身份。
優點-客戶端請求不依賴服務端的資訊，任何多次請求不需要必須訪問到同一臺服務，這樣為伺服器橫向擴充套件提供了條件。
服務端需要記錄每次繪畫的客戶端資訊，從而識別客戶端身份，根據客戶端身份進行對請求的處理，如session。
缺點
-服務端儲存大量客戶端資訊，增加服務端壓力。
-服務端儲存使用者狀態，無法進行水平拓展。
-客戶端請求依賴服務端，多次請求必須訪問同一臺伺服器。
來自相同客戶端發起的請求在服務端是否具備上下文關係。服務端儲存狀態化請求的相關資訊，每個請求可以預設地使用以前的請求資訊。服務端處理無狀態請求時，資訊必須圈閉來自於請求所攜帶的資訊以及其他服務端自身儲存的並且可以被所有請求所使用的公共資訊。
服務呼叫過程中有兩種「狀態」：應用狀態和資源狀態。應用狀態是某一特定請求的相關資訊。資源狀態則反應了某一儲存在服務端資源在某一時刻的特定狀態，該狀態不會因客戶請求而改變，任何使用者在同一時刻對該資源的請求都會獲得這一狀態的表現。
儲存狀態限制了分布式系統，如負載均衡時，乙個使用者的請求必須被提交到儲存有其相關狀態資訊的伺服器上，否則這些請求可能無法被理解，這也意味著再次模式下伺服器無法對客戶的請求自由排程，另乙個問題就是容錯性，儲存使用者資訊的伺服器宕機，那麼該使用者最近的所有互動操作將無法被透明底移送到備用伺服器上，除非改伺服器時刻與主伺服器同步全部使用者狀態資訊。此外由於http本身不是乙個有狀態的協議，開發者必須通過模擬實現狀態的鈍化與啟用等。無狀態架構風格有效的克服了這些不足。
無狀態大大提高了服務集群的可伸縮性、在橫向擴充套件或集群部署時不用狀態重建，無狀態是針對服務端來說的。
狀態化的服務在功能實現方面有更大的優勢，但由於需要維護大量資訊和狀態，在效能方面要遜於無狀態伺服器。無狀態在處理簡單服務方面有優勢，但複雜功能方面有很多弊端。如用無狀態服務實現實時通訊？有句話總結的比較貼切：無狀態不是消滅了有狀態架構的問題，而是將有狀態架構的問題延後了。
架構設計原則 高併發
架構設計原則 高併發 高併發設計可以從以下幾方面考慮 1.無狀態 無狀態的應用容易進行水平擴充套件。實際常用 應用無狀態，配置檔案有狀態，例如，不同的機房讀取不同的配置檔案，通過配置中心指定。2.拆分 拆分維度 3.服務化 服務化需要考慮自動服務註冊，和服務發現，還有服務的分組 隔離，例如，有的系統...
高併發架構設計原則 拆分
在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。訪問量不大 功能簡單 研發資源不多時可以做乙個大而全的系統即可 如果訪問量大資源充足 功能繁多可以考慮按功能拆分系統。下面幾種拆分維度 按照系統功能 業務拆分，比如商品系統 購物車系統 結算系統 訂單系統等。對乙個系統...
高併發架構設計原則 訊息佇列
解耦 消峰 非同步 有abcd四個系統，a系統有一條資料需要傳給bcd，a系統不僅要關心資料傳送還要處理資料傳送bcd其中產生的異常，如b掛掉了怎麼辦，a是否重傳？如果使用訊息佇列，a系統只負責傳送訊息到訊息佇列，bcd消費訊息佇列中的訊息即可，a系統不關心訊息發給誰了，誰消費失敗了等等問題。類似於...