網站登錄校驗，很普通的一個功能 對於這個功能我們要如何實現？

先分析一下登錄校驗是個啥意思 舉個栗子，比如我們在登陸頁輸入用戶名密碼，登錄了社交網站 這時候想去看自己的新鮮事，卻告訴我請先輸入用戶名密碼進行驗證。。 這時候想去吐槽下這個2B體驗，發個新鮮事，點完發布按鈕時，又彈出框說請輸入用戶名密碼進行驗證。。。這時候腦子裏上千個草泥馬奔騰而過

這樣的產品可以說拜拜了

對我們的用戶來說，登錄操作其實完成一次就夠了，後續的操作服務應該能夠自動識別出是這個合法用戶 因此，我們就需要對用戶的狀態進行記錄，後續直接在後臺裏自動幫用戶進行校驗

OK，需求分析完了，那該怎麽實現呢？

in the old time 我們直接通過session的方式，單機時代很方便，也夠用了

隨著用戶量和訪問量的增大，單機似乎不夠用了，加一臺機器吧 這時候也引入了負載均衡服務，對應用服務器上的session也增加了同步的邏輯 比以前稍稍復雜了些，但也還好。但是如果用戶量不斷增加，訪問量不斷變多 繼續加應用服務器，加一臺，兩臺。。十臺。。。？ 這個session同步機制怎麽保證依然快速有效？ 這麽大量的數據同步，帶寬資源的消耗很可觀啊 另外，N臺應用服務器都有相同的session副本，這是對內存資源的極大糟蹋啊

那麽有沒有更加優雅的方案呢？

這裏舉一個方案 采用cookie + session服務器的方案 1.用戶在登錄頁完成登錄操作後，服務器會生成一個登錄session信息，保存起來，設置個失效時間，並設置到用戶的cookie裏 2.用戶後續的每次請求裏會帶著這個cookie信息，服務端會對這個cookie信息進行校驗，通過了就認為是合法用戶，執行請求操作

這個方案的好處比較明顯 應用服務器變成無狀態了，對session的統一管理由專門的服務來處理

引出了今天的主題：有狀態和無狀態

什麽是有狀態和無狀態 這個話題結合系統設計，拿應用服務器來說會容易理解

像剛才介紹的，應用服務器裏持有用戶的session，這時應用服務器是有狀態的 因為保存了用戶會話這個上下文信息，後續的用戶請求都會需要訪問這個session信息 多個應用服務器之間是副本的關系，需要保持session數據的同步

無狀態的應用服務器，像剛才把session挪出應用服務器，由專門的服務進行管理 此時應用服務器不保存上下文信息，只負責對用戶的每次請求提交數據進行處理然後返回處理結果 無狀態應用服務器之間是對等的關系，無依賴，請求到哪個服務器，處理結果都一樣的

有狀態的服務，會有比較明顯的缺點，服務間數據需要同步，成為副本關系，邏輯復雜也浪費資源 相對來說，無狀態的服務，就會簡單多了 可以來做個比較

對於高可用服務的構建要求來說，快速failover以及快速擴容是非常重要的 服務有狀態，服務當機就可能會存在數據丟失 關鍵是快速擴容，有狀態服務會有冷啟動的問題，還需要先加載數據才能對外提供服務，太麻煩了

所以大家在進行系統設計時，時刻要有這個意識，我們的應用服務器，要設計成無狀態 不保存任何上下文信息

拓展學習： CAP理論 其實有狀態服務也有其自身的好處，數據狀態在服務中保存，無需額外的調用，低延遲 不需要額外的存儲，服務本身已經存了

關於構建可伸縮的有狀態服務，可以看下這篇文章的介紹 http://www.infoq.com/cn/news/2015/12/scaling-stateful-services

如果要構建有狀態的服務，那就有必要了解CAP理論了 先看下維基百科對CAP的介紹： In theoretical computer science, the CAP theorem also known as Brewer’s theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees

• Consistency (all nodes see the same data at the same time)
• Availability (a guarantee that every request receives a response about whether it succeeded or failed)
• Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)

大名鼎鼎的CAP理論的意思是說，一個分布式系統無法同時滿足三個條件 一致性、可用性、分區容忍性

一致性，數據要保證一致，保證準確性 可用性，我們的服務要保證24小時可用 分區容忍性，訪問量太大了，要擴容，體現為系統的可伸縮性了，部署多個實例或副本

但是呢，擴容了，保證了可用性，數據一致性怎麽保證？ 副本這麽多，同步機制太難做好了。有個經典有趣的問題：拜占庭將軍問題，感謝可以去了解

互聯網公司一般會選擇保證AP，保證高可用，但是一致性呢，該怎麽辦 CAP理論並不完全適用於指導實際的工程開發，所以對於一致性，一般會這樣去考慮

強一致性，必須保證一致性，任意時刻都能讀到最新值。這個，呵呵 弱一致性，寫入新值後，在副本上可能讀出來，也可能讀不出來 最終一致性，在某個時間後，能夠讀到最新的值

CAP理論相關的知識涉及面比較廣，大家感興趣可以多看看，這裏就先介紹到這裏 左耳朵耗子有篇文章，對分布式系統的理論進行了些介紹，感興趣可以看看 http://coolshell.cn/articles/10910.html

最後回到今天的主題，我們在系統設計上，遵循的原則還是簡單為主 通過簡單的設計來滿足我們的業務需求 如何簡單？非特殊情況，都設計成無狀態的吧

最後再補充個題外話： 開頭所講的栗子裏提到使用cookie，這個可能會存在安全的問題 比如XSS，跨站腳本攻擊。可能會導致cookie信息被竊取，所以需要對XSS進行安全防護了

web安全又是一大塊知識啊，感興趣可以自己深入學習

來源：http://blog.csdn.net/zhoumingp/article/details/50457203

聊聊系統設計：有狀態、無狀態