前天接到一個項目，需要採集用戶行爲進行分析，例如：有N個頁面，每個頁面有都按鈕和鏈接，需要記錄每次用戶一些特徵行爲，如：
特徵行爲一：A頁面點擊一個按鈕跳到B頁面，然後在B頁面點擊一個鏈接跳到C頁面，然後在C頁面點擊下載。
特徵行爲二：D頁面點擊按鈕跳到E頁面，然後在E頁面點擊按鈕跳到C頁面，然後在C頁面點擊下載。
兩個特徵最後都在C頁面下載軟件，現在需要統計A-B-C-下載和D-E-C-下載這兩種行爲的分佈（頁面的訪問時間，人數等），幫助運營更好的運營網站，這個有點類似AB測試，當然特徵不止這兩種，另外網站目前大約在20萬UV，將來可能擴展到500萬-1000萬的UV，如何構建這個這個採集系統。
很多人拿到這個項目的時候就會直接想到在session中記錄這中特徵軌跡，然後插入數據庫，在數據庫裏面做統計，每天統計一下1000萬級別的數據量最多也就1-3個小時就分析完，當然這個看來是可行的，也最簡單。
但是要考慮到一個問題，如果這個網站有100個頁面，每個頁面有3個按鈕。那麼這種組合將會是100*100*3=30000種組合（這個只是兩個頁面的組合，不算多個頁面的組合，當然運營也不會要求30000種組合的統計數據，他們也看不過來），用程序來維護這些組合且不說系統的設計將會有多複雜，就完成這種組合的解析工作將是一個巨大的工作量，有沒有什麼好的辦法呢。
辦法當然是有的，記住一點用戶想要的最終系統不一定是我們要做的，我們分析一下這個需求的實質，首先我在前面是提到了一個詞"組合"，從"A-B-C-下載"我們其實可以解析成一下動作
來源頁 當前頁 動作
PX PA A1 //PX表示未知頁，PA表示A頁，A1表示點擊動作1
PA PB A2
PB PC A3
我們來分析一下這組數據來源頁可以看成一個可變量A，當前頁看作是可變量B 動作可以看成是可變量C，這樣一來就有了三個可變量（其實就是可變量分析），這可以就可以完全套用經典的設計模式中的橋模式來設計這個系統。我們只需要記錄每次點擊的來源頁，當前頁和動作就完全可以分析出來我們想要的用戶行爲軌跡。
我們中設計結果的好處就是當然運營需要一種軌跡的的時候只需要將模型告訴我們，然後用程序實現掉進行編號，在用模型來解析這些數據將最後結果插入數據庫，當然數據庫的設計也很簡單，值需要"序列號，模型ID，IP，servertime，clientTime，paramStr"6個值就行了，也就是說數據庫不需要知道具體模型是什麼，他只要進行IP，和時間還有參數三個緯度的分析就行了。以後無論想要什麼樣的用戶軌跡我們只需要將其轉化爲模型實現分析後插入數據庫，再由數據庫分析後得出分析結果，這裏有用到了一種設計模式，那就是適配器模式將不同的業務需求轉換爲同一個類型的結果輸出，這樣一來從整個程序的擴展性和可維護性來說有是有好處的。
下面在這個是程序設計上的架構，接下來就是系統架構。看以下系統結構圖
採集服務器收集上報數據，這些數據以文本方式存放，如果直接插入數據庫的話一個是網絡上不安全，一個是數據庫會受不了高併發的插入操作。
由於預測將來將會有有500-1000萬UV，所以需要將採集服務器設計成可橫向擴展的，所有的採集數據文本將在分析服務器上彙總，目前由於數據較少，大約每天產生1G數據，單個分析服務器完全可以勝任，如果以後業務量增加，可以輕鬆部署hadoopp來做分析，最後數據庫基本上不會有什麼壓力，因爲經過處理的數據放入數據庫之後只有很少一部分，可以看看擴展之後的整個系統結構。
還是有點有規模的，整個設計在業務和硬件上的擴展都是很靈活的，拿出來分享一下，也希望大家在各自的應用中能夠更多的使用設計模式來將系統設計得更加靈活。
