如何解決京東商城的性能瓶頸？
原創【51CTO快訊】京東商城在昨天搞了一個“京東圖書瘋搶三小時”活動，不過卻因為大量的“網頁無法顯示”，訂單無法提交而招來用戶的一片罵聲，最終僅產生數十萬訂單，平均一秒鐘才幾十個。
51CTO推薦專題：電子商務浪潮下的服務器高并發應對方案
做活動搞得服務器頂不住，京東已經不是***次遭遇。京東CEO劉強東昨天發布微博數篇，表示要“增加三倍服務器，活動再搞一次”，以及要請“信息部同事們喝咖啡”。
事實上，不僅京東商城有此困惑，其他的不少電子商務網站也有這樣的困惑。根據一些業內的數據，在國內的眾多電商網站當中，除了阿里的服務器過萬外，其余的大多在500-2000之間，且大多數是.NET架構。劉強東在早期做過一些財務系統和小的企業級應用系統，京東也因此在早期選用了.NET架構；然而，互聯網這種高并發、大流量的應用環境和企業內部環境是有非常大的區別的。京東商城目前維持30萬的日平均訂單量已然不易，一旦要進行活動，用戶訂單一擁而上，現有的架構根本無法處理。
那么，京東要如何才能擺脫現在的困境？
從運維的角度來看，僅僅增加三倍服務器肯定帶不來三倍的并發訂單處理能力。在劉強東當天的微博后面現在已經有9千多條評論，其中不少來自技術人；在筆者所在的一些技術群里也在討論這個問題，其中不乏有見地的評論。小編從中挑選一些，整理如下：
管理、人才方面
李錚_Reason：活動之前沒有對預期流量進行充分評估么？這種活動不是經常進行，增加3倍服務器是否會浪費資源？活動在搞一次，是否合算過財務，是否問過市場部？從公司來講還是要尊重各個部門的努力；從營銷來講，這條微薄估計比一個Q的營銷效果都好。
霍泰穩: 也許京東從這件事上能夠了解技術人員其實挺重要的，多讓技術人員外出交流還是很有必要的。此前邀請京東的朋友出來分享，總是很困難！
焦若雷：動態應用的突發看來依然是京東包括很多未來量會增長到很大的電子商務網站的瓶頸。出現這種問題的原因可能與你們業務線和運維的溝通不充足有關，但也不排除本身你們在大規模動態應用突發上的運維管理經驗缺失及技術缺失。
老熊:大的電商，不叫技術部，叫信息部，京東也是獨一家吧
Norman程：市場部是否有把這次活動可能導致每小時進十幾萬的訂單的信息傳遞到各個業務系統呢？今天是門戶及訂單系統宕機，明天會不會是供應鏈和物流呢？
程序員-釗雄Johnson：（一）從技術的角度，服務器壓力均衡不是靠增加幾臺服務器就能解決的問題。淘寶積聚著一批優秀的JAVA人才，數據庫人才，天天為服務器保駕護航，保證了正常運行。多方面的技術積聚，才是問題的解決。您作為老大，您為您IT部門做了哪些？電子商務，無電子，何來商務。
程序員-釗雄Johnson：（二）京東采用.NET平臺，在均衡壓力上需要積累。它需要***的團隊，***的管理制度，足夠的技術積累。人才，***的待遇，招***的人才。京東，或者這次事件只是一個開始，它應該不是一個偶然，應該說是個必然。技術不革新，人才不革新，問題還是遲早爆發。
@池建強:在技術上淘寶和京東完全不是一個層面上的，看看各個技術大會淘寶的分享吧。這種情況下談什么Java還是.Net，就毫無意義了。
kwkmko：全面一點吧，市場部和策劃部有沒有計算或者預計一個比較靠譜的流量？并且遞交給信息部備案？財務有沒相關條款支持設備更新？總協調人是否預計到這樣的情況？信息部有沒有預算支持應急的設備……
池建強: 阿里玩的是平臺，順道把電商做了；京東玩的就是電商，順手搞搞技術。
技術改造方面
南非蜘蛛: 是不是應該先找出瓶頸，優化架構，加機器也不一定可以徹底解決
靜觀參眾妙：作為一個軟件從業人員，我完全理解今天上午服務器經常出現service too busy的現象；但作為一個軟件測試人員，我完全不能理解京東的業務系統貌似沒有經過嚴格的大數據量壓力測試。
foxtree：壓力在數據庫，不是多幾倍服務器能搞定的，除非程序重構適應分布式的硬件
雪中飛_：量變引起質變吧，并發量小的網站剛開始可以不太關注底層技術架構，量大的網站要提前布局，否則到時候就措手不及。而底層技術平臺需要時間和經驗去堆積。
何雪峰：這個不是簡單加服務器就能解決的，涉及接入帶寬數，數據庫并發處理能力，中間層并發處理能力，京東訂單系統并發處理能力，磁盤寫入速度，排隊事務處理
kewell119：建議你們看看《編寫高質量代碼—改善C#程序的157個建議》
淘寶四虎：有了這么大的壓測量，應該收集不少性能數據，接下來好好分析性能瓶頸，花個半年時間解決一下。
365-姜志林：就情況看，問題可能出在數據庫，web端向數據庫大量提交訂單，db并發造成死鎖等待。web端繼續等待，建議采用分布式設計及文件級數據緩存，同時優化底層數據庫設計。
霧散云暖：時間再長也沒用，關鍵要改進你們的后臺，學學人家亞馬遜、當當，首先備貨要足，其次購物車要能保留信息，第三貨品搜索頁面上***直接根據ip地址或者啥的顯示出當地有無貨狀態
京Piedro-Conte董金：我覺得比較現實的還是 請IBM 之類的公司 給京東做設計（編者注：雖然IT外包一般不是互聯網企業的優先選擇，不過隨著互聯網技術的細分，由于術業有專攻，細分領域的外包相信也會逐漸變成趨勢。）
大熊：其實，這個時刻最應該給京東提供幫助的是微軟。微軟應該考慮無償給京東這樣的電商大鱷提供.Net的所有技術服務，甚至更多幫助。因為，像京東這樣有著幾千人研發團隊的企業還堅持使用.Net架構的已經幾乎沒有了，如果連京東都這樣一掛再掛，很難相信以后還會有哪個大型商業網站敢再選用.Net架構。
有關彈性云
數據中心亂彈:是否可以租賃amazon的計算能力應急突發高峰？或國內誰會***推出類EC2這種服務？
zysno1: 如果是這種規模的企業使用彈性計算，其實不需要全部hosting上來，它可以用彈性計算來支撐那部分突增。就類似CDN那樣。彈性計算使這種階段性的資源使用方式成為可能
你對于國內電子商務遇到的這種困境有何看法？歡迎探討！
【51CTO.com獨家特稿，轉載請注明原文作者和出處。】
【編輯推薦】
