關於狀態還是無狀態這2種伺服器架構，我在以前的一篇文章：《狀態和無狀態－－2種伺服器架構之間的比較》http://blog.csdn.net /romandion/archive/2007/09/25/1800025.aspx 做了論述，也涉及到高可用高效能方面，現在想做一些補充。
一、核心區別
每個伺服器的架構，通常可以簡化為請求和應答的過程，狀態化和無狀態化的最核心區別在於，伺服器應答過程是否基於上次請求所構築的上下文環境。一般說來， 無狀態化架構基於請求所攜帶的資訊，如果請求所攜帶的資訊比較簡單，象http中表單，其實也可以將這部分狀態化架構歸於無狀態化架構。而狀態化架構的響 應則依賴於伺服器中的上下文環境，比如**交易系統中，要發起委託，則必須先登陸，否則資金、持倉等資訊都無法獲取。無狀態化架構也可以模擬狀態化結構， 比如在http中，可以攜帶cookie，或者是服務端的會話id，這種方式其實也是為服務端指定了上下文環境，實際上可以歸結到狀態化架構中。
二、請求遷移
無狀態化架構的響應條件完全基於請求所攜帶的內容，所以比較容易遷移，在發生錯誤的時候，由於發生錯誤節點並沒有儲存請求的上下文環境，所以由另外乙個節點來處理完全可能獲得相同的結果【
注意：是可能】， 而狀態化架構在發生錯誤時，其他節點可能無法構築相同的上下文環境，或者構築相同的環境代價巨大。我們可以看到無狀態摒棄了上下文依賴，「無官一身輕」的 自由，不過在請求攜帶會話id的應用中，並沒有這個自由。但我們也必須注意到，如果請求中包含資源的申請，那就不一定能夠獲取正確的結果了，比如檔案傳 輸。
狀態化架構如果不是儲存上下文資訊的節點失效，那麼實際上並不會造成影響。或者上下文環境能夠比較容易地被重新構建出來，那麼狀態架構完全可以獲取和無狀 態同樣的自由。這個情況在多數情況是比較困難的，比如在網路遊戲中，乙個角色的上下文環境可能包含很多角色資訊，裝備資訊以及其他雜七雜八的資料。不過， 我們可以採取幾種策略來達到這種效果。
1、儲存分割：乙個請求所需要的上下文環境即使再複雜，他在一次處理中不會同時用到。我們可以按照某種策略，將這個環境分割成多個單元，放在不同的地方。將不太容易發生變化的資料儲存到資料庫中，而將容易變化的資料和另外乙個節點同步。
2、增量日誌：將資料的變化過程轉化成增量日誌，當節點失效後，我們可以從失效點開始重構上下文。
3、狀態前置：在該節點之前，有個地方儲存可以重現上下文的狀態，該狀態可以移植到其他節點，重構上下文。
這種請求遷移不一定要在節點失效的情況下發生，而且很有可能是在負載過大的情況下發生。請求是否可以遷移是可用高效能系統的重要標記。狀態化架構在這樣處理之後，比較容易實現遷移，在負荷均衡方面作用就很大了。
三、實時響應
實時響應是伺服器對客戶端的響應時間小。在客戶端主動請求時，並不能看出這2種架構對響應時間的影響，因為同樣依賴於伺服器的處理能力。但當伺服器需要主 動推動客戶端處理時就不一樣了，比如**交易的風險類別的提示，這類計算多數是在服務端完成的，我們需要實時監控**的變化，當合約的**達到我們期望的 時候，需要馬上作出處理。這時候需要伺服器主動向監控者傳送資訊。
在狀態化架構中，我們可以從伺服器中儲存的上下文環境知道監控者在**，然後向他傳送訊息。但是在無狀態化架構中，伺服器中沒有任何監控者的訊息，只能等 監控者傳送請求時，向他傳送訊息，這是被動的處理方式。監控者在這種架構中只能採取定時的方式，如果在時間極度敏感的環境中，這個顯然是無法實現的，因為 時間間隔是無法跨越的鴻溝。
這種情況同樣會出現失效檢測中。無狀態化架構中，只能由客戶端傳送心跳請求，服務端被動地判斷。而在狀態化架構，伺服器把握更大的主動性，因為他可以主動地去監控客戶端。
四、資源儲存
不論哪種架構，只要他們涉及到對資源的訪問，那麼他們就面臨同樣的制約：資源儲存。在web/p2p中，主要是對檔案等靜態資源的訪問，這些資源沒有變 化，因此當請求被遷移時，可以獲取同樣的結果，這個過程對狀態化架構是同樣適用的。不過在資源儲存節點失效時，我們必須看到如果資源儲存不是在多個節點具 有相同的備份，哪種架構都沒招。
如果是訪問變化頻繁的動態資源時，狀態化架構比無狀態化架構更具優勢。因為狀態化架構對變化具有更強地感知能力，可以實現增量更新的操作。無狀態化架構只能讀取全部的資料，或者由其他服務來提供需要的資料。
曾經在**交易系統中實現風險控制級別的計算，這個演算法涉及到**資料，客戶的資金、持倉。**資料還好說，可是客戶的資金和持倉是在資料庫中的，對於風 控伺服器來說，沒法感知到他們的變化，乙個折中的辦法就是發個請求給資料庫，讓他從操作日誌中，解析出變化的資料再來更新本地的資料。其實這種方法對資料 庫來說是很為難的事情，但是對於無狀態架構來說，完全沒有辦法。
資源儲存和實時響應其實都涉及到變化的感知能力。當資源儲存失效時，重定向到正確的資源儲存點是最關鍵的問題。
五、長短連線
長短連線指的是連線的保持時間，一般說來，無狀態化架構傾向於短接連【如：http】或者無連線，而狀態化架構傾向於使用長連線。這是因為無狀態化結構沒有上下文關係，所以保持連線對他來說是沒有必要的；而狀態化架構往往需要連線來判斷上下文關係，同屬於乙個連線的前後2個請求就屬於同乙個上下文的請求。
這種關係的判斷主要應用於tcp/ip的時候，如果在虛擬網中，這種關係會被模糊掉。 因為在虛擬網中，客戶端極有可能是長連線在路由服務中的，但他傳送的請求被路由服務**到不同的服務節點，這時候，極有可能是無狀態化架構。不過長連線對狀態化架構支援得更好，畢竟長連線容易標識上下文環境。
高效能，高可用系統架構
本文是學習大型分布式 架構的技術總結。對架構乙個高效能，高可用，可伸縮，可擴充套件的分布式 進行了概要性描述，並給出乙個架構參考。一部分為讀書筆記，一部分是個人經驗總結。對大型分布式 架構有很好的參考價值。1 大型 的特點 2 大型 架構目標 3 大型 架構模式 4 高效能架構 以使用者為中心，提供...
高可用高效能系統（二）系統異常場景
一 網路故障 當客戶正在交易時，突然網路發生異常，導致無法繼續連線到網路上。這個場景是最可能發生的。我們需要在網路發生的時候，讓客戶能夠繼續進行這個交易。二 效能故障 由於機器效能或者軟體效能的緣故，可能會導致我們在某個業務處理過程中耗費大量時間，比如資料庫查詢。但是這也不應該影響我們進行繼續交易。...
做高效能，高併發，高可用系統要注意的問題
系統架構三個利器 rpc服務元件 訊息中介軟體 互動非同步化 流量削峰 配置管理 灰度發布 降級 無狀態 介面層最重要的就是無狀態，將有狀態的資料剝離到資料庫或快取中 如何改善延時 找關鍵路徑 28原則 空間換時間，如各級快取 時間換空間，如傳輸壓縮，解決網路傳輸的瓶頸 多核並行，減少鎖競爭 更適合...