http://os.51cto.com/art/201203/321067.htm
2011年京東商城碰到了嚴重的流量相關的性能瓶頸，51CTO也做了專門的報道，我有幸在6年前主持開發過日流量千萬級別的系統，所以也在微博發表了一下自己的觀點（具體詳見 http://os.51cto.com/art/201111/300247.htm）
不是每個人都有幸親自參與並主持設計大型網絡應用的，我應該說就是其中的幸運兒之一吧。我在2003年畢業後投身IT界，先是在國內某知名的棋牌遊戲公司擔任了3年的程序員；06年有幸參得到一個機會主持開發了一個日流量2000萬級別的互聯網應用。09年轉做市場運營，時間過去3年多了，現在技術日新月異，或許當年的設計已被替代。作爲一個技術圈的退役老兵，仍堅持將自己的設計模型寫出來，跟大家分享學習，並歡迎大家批評指正。
本文只做拋磚引玉的作用，具體實施歡迎與我互動。
項目概況 某大型網絡應用，含普通的用戶功能（如登錄、信息修改等）；含信息發佈功能；含統計功能（如信息查看、點擊等）；以及其他周邊功能。
硬件配置 數據庫服務器1臺；中央應用服務器1臺； web服務器20臺（可靈活擴充）。
設計思路
通過購買專業的DNS服務，將域名流量按照區域（如北京，浙江等）和服務商（如電信，網通等）分發到不同的web服務器N,在每一臺web服務器安裝並部署web項目；每臺web根據用戶的不同命令讀寫本機緩存XML；
中央應用服務器定時的獲取多臺web服務器的緩存xml文件，進行應用級的數據分析彙總，並將結果寫入數據庫服務器；
中央應用服務器定時的獲取數據庫服務器信息，並同步到多臺web應用服務器。
設計難點及解決辦法
WEB服務器版本控制
解決辦法：爲每臺web服務器配置並標註好版本號；在中央應用服務器做好版本兼容性工作。如：web程序的統計功能，新版本V1.1去掉了老版本V1.0中的IP統計。Web服務器1的當前web版本爲V1.0，Web服務器2的當前版本爲V1.1。在中央應用服務器需提供兩個方法，TongJi-v10()和TongJi-v11()。在v10的方法中先做數據校正，再調用新方法v11。
中央應用服務器海量數據傳輸
解決辦法：假設一臺服務器承載200萬的流量，將產生大量的應用數據。可以先將這些數據在web端進行壓縮後再傳輸，能節省80%以上的帶寬成本。
數據的及時性
數據及時性是使用文件緩存比較棘手的問題之一。
解決辦法：對數據及時性進行歸類。在設計期間，我們將數據的及時性簡單的劃分爲三個級別，按需，高及時和非及時。按需數據立即同步；高及時信息每10分鐘同步到中央應用服務器，低及時信息每小時同步。這其中，比較有意思的是一些看似按需的操作也並非真正的按需操作。如用戶密碼修改，修改後的密碼密文就存在web服務器N的xml配置文件中，就能確保用戶使用新密碼登錄。用戶在沒有切換線路或者更改區域的情況下，仍然是使用的web服務器N，也無需按需同步密碼數據，只需要高及時同步。
數據的安全性
大量Web服務器存在着大量的數據，甚至包含賬戶或者資金信息，某種意上講這些數據是不安全的。
解決辦法：文件存放路徑、加密、模糊。不要將xml緩存文件存放在web路徑可以供用戶下載的地方，配置絕對的硬盤路徑來設置配置文件的讀寫。如賬戶的密碼只存取MD5加密字串，如資金採取多套對稱加密算法加密，用不要用password來標識字段爲密碼而採用I1，不僅能模糊字段還能節省磁盤及後續傳輸消耗.
