分佈式系統開發常見問題

1. session的複製與共享

在web應用中，爲了應對大規模訪問,必須實現應用的集羣部署.要實現集羣部署主要須要實現session共享機制,使得多臺應用服務器之間會話統一, tomcat等多數主流web服務器都採用了session複製以及實現session的共享. 但問題仍是很明顯的：

在節點持續增多的狀況下,session複製帶來的性能損失會快速增長.特別是當session中保存了較大的對象,並且對象變化較快時,性能降低更加顯著.這種特性使得web應用的水平擴展受到了限制.

 

session共享的另外一種思路就是把session集中起來管理,首先想到的是採用數據庫來集中存儲session,但數據庫是文件存儲相對內存慢了一個數量級,同時這勢必加大數據庫系統的負擔.因此須要一種既速度快又能遠程集中存儲的服務：memcached

使用memcached來存儲session有兩種方案:

(1)直接經過tomcat6的擴展機制實現.

Reference: http://www.javaeye.com/topic/81641

(2)經過本身編寫filter實現.

考慮到系統的擴展,咱們採用這種方案.這樣可使session共享機制和中間件脫鉤.

Reference: http://www.javaeye.com/topic/82565

主要思路:

1)繼承重構HttpServletRequestWrapper,HttpSessionWrapper類,覆蓋原來和session存取相關的方法呢,都經過SessionService類來實現.

2)使用filter攔截cookie中的sessionId,經過sessionId構造新的HttpServletRequestWrapper對象,傳給後面的應用.

3)SessionService鏈接memcached服務,以sessionId做爲key,存取的對象是一個map.map的內容即爲session的內容.

 

使用過程注意幾個問題和改進思路： 
一、memcache的內存應該足夠大，這樣不會出現用戶session從Cache中被清除的問題(能夠關閉memcached的對象退出機制)。 
二、若是session的讀取比寫入要多不少，能夠在memcache前再加一個Oscache等本地緩存，減小對memcache的讀操做，從而減少網絡開銷，提升性能。 
三、若是用戶很是多，可使用memcached組，經過set方法中帶hashCode，插入到某個memcached服務器

 

(3)使用memcached-session-manager管理session

Reference: http://www.iteye.com/topic/1125301

對於session的清除有幾種方案:

(1)能夠在凌晨人最少的時候，對memcached作一次清空。

(2)保存在緩存中的對象設置一個失效時間,經過過濾器獲取sessionId的值,按期刷新memcached中的對象.長時間沒有被刷新的對象自動被清除.(相對複雜,消耗資源)

2. 分佈式緩存的設計：在多臺Node的環境下，產生的緩存以及緩存的變化，如何處理？

To be continued...

3. 數據庫的sharing, 當數據量愈來愈大，數據須要遷移時，對不一樣的分庫，分表（區），業務數據處理層如何可以適應底層的變化?

使用DDL：Sharding擴容方案-全局增量+局部hash散列

一個大型的互聯網 應用必然會通過一個從單一DB server,到Master/salve,再到垂直分區（分 庫），而後再到水平分區（分表，sharding）的過程(隨着用戶量的不斷增長，你會發現系統中的某些表會變的異常龐大，好比好友關係表，店鋪的參數配置表等，這個時候 不管是寫入仍是讀取這些表的數據，對數據庫來講都是一個很耗費精力的事情)，而在這個過程當中，Master/salve 以 及垂直分區相對比較容易，對應用的影響也不是很大，可是分表會引發一些棘手的問題，好比不能跨越多個分區join查 詢數據，如何平衡各個shards的 負載等等，這個時候就須要一個通用的DAL框架來屏蔽底層數據存儲對應用邏輯的影響，使得底層數據的訪問對應用透明化。

拿淘寶目前的狀況來講，淘寶目前也正在從昂貴的高端存儲（小型機+ORACLE）切換到MYSQL,切 換到MYSQL以 後，勢必會遇到垂直分區（分庫）以及水平分區（Sharding）的問題，所以目前淘寶根據自 己的業務特色也開發了本身的TDDL(Taobao Distributed Data Layer)框架，此框架主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製。

淘 寶網採用什麼技術架構來實現網站高負載的呢？淘寶的總體架構使用了以下措施來應對：一應用無狀態(淘寶session框架)；二有效使用緩存 (Tair)；三應用拆分(HSF)；四數據庫拆分(TDDL)；五異步通訊(Notify)；六非結構化數據存儲(TFS,NOSQL)；七監控、預警 系統；八配置統一管理。

http://code.taobao.org/p/tddl-dynamic-datasource/wiki/index/

4.  鐵道部網站爲什麼登陸會掛，進入以後就不會。

登陸的時候，由於沒有足夠的服務相應用戶的查詢請求，負載均衡不夠，服務器很是繁忙，致使沒法登陸。登陸進入的人少了，那登陸進去的用戶基本上在網站的承載範圍內，因此登陸以後只會慢，不會掛掉。

使用CDN, 足夠的服務器集羣，負載均衡，緩存存取用戶信息，經過測試讓系統容量可以達到2kw級別，便可讓更多的用戶登陸進系統。真正的問題不在登陸，而在登陸以後的對票的查詢與巧奪。查詢能夠經過單獨的查詢集羣服務來解決。最困難的是最有限的資源的爭奪（1.火車票的狀態是實時計算，實時更新的；2.火車票資源稀缺，須要同線下數以萬計的購票點、電話訂票等進行互斥。每張火車票都是獨一無二的，網絡售票只是數以萬計的購票終端的一個終端而已，須要跟其餘售票系統保持數據一致性）。

solution 1: 設定容忍度: 絕對不能兩我的訂到同一張票，而看到有票，而點擊了下訂單又說沒票了這種失誤是能夠容忍的。

solution 2: 排隊，異步告知前面多少人，輪到以後，規定時間下單（查詢須要的票，下單到的票鎖住，timeout則踢出）

solution3: 100w有效點擊的用戶，隨機搖出可否負載的用戶數（10w）

點擊訂票以後，進入前置分析機，分析機負責計算背後的機器能負載多少用戶下訂單。好比目前有1百萬人同時點擊了訂票，而背後只能負載10萬人，那麼出現一個隨機搖號程序，搖出10萬人，其餘人返回 「系統繁忙，稍後重試」的提示。這10萬人被負載在10臺機器上，能夠進行查詢，當點擊指定車票（標記爲ClickSelectedTicket）後，根據車票被分散到不一樣的機器上（實際上是MapReduce的思想）。好比有1萬人被定位到要訂票T1，系統扔出900張T1票，留100張容錯（隨着系統逐步穩定，可減小容錯票數），而後你們搶鎖，採用樂觀離線鎖。在最終提交訂單時檢測。

轉載：」當 前 12306 系統一個很受人詬病的實現就是沒法登陸。用戶打開登陸頁，輸入了用戶名密碼，還耐心的填好了驗證碼，點擊提交，再耐心的等了 30 秒，結果，彈出一個無比醜陋的對話框，說「當前訪問用戶過多，請稍後嘗試」。讓用戶登陸進來，給他們能買到票的但願，是減小投訴的一個很重要的方面。這個 其實一點也不難：將用戶信息都加載到 Redis 內存，簡單點，key 就是 email，value 就是密碼加密串，用 cookie 而不是 session 進行身份驗證，用 ajax 而不是刷新頁面的方式提交數據和返回應答，這麼一來，即便 2 kw 用戶同時都登陸進來，也只須要三五臺 tomcat ，20分鐘就搞定了。「

優化方式：http://blog.csdn.net/fyxxq/article/details/8850531     http://blog.csdn.net/li0531/article/details/7991176