主要還是資金問題啊。

現在，各種技術架構都算已經比較成熟的情況下，併發其實很容易解決，就是擴容。簡單理解就是加伺服器和拆分服務。

新浪微博流量具有瞬間峰值高、持續時間短，這讓新浪的運維人員都非常難辦，平時流量可能是熱點事件時的1%，如果平時就按照熱點事件的資源去運維，新浪可能沒幾天就運營不下去了。

因為維持大量的伺服器和儲存資源需要的成本高到難以想象。

而淘寶平時流量都能預估，幾乎不會出現突然的峰值流量。像雙十一，更是提前一個月可能就已經做好了預案，伺服器該加的，該擴容的擴容，效能該升級的升級，等到雙十一一過，再把這些資源釋放掉。

這成本就控制下來了。

首先，新浪實際盈利能力是不如淘寶的，因此不可能為了幾次熱點事件，就把大量資金都投入到這些伺服器資源中。畢竟這樣投入，幾乎是全浪費掉的。

什麼時候新浪真的盈利能力非常強，一擲千金，直接把伺服器資源頂到熱點事件的級別，那新浪也不會宕機，更不會讓你感覺到併發差。

錢和人才堆積起來的，換位思考一下，新浪的後臺已經不錯了，除了BAT，能夠比新浪的併發能力強的，也沒多少個了。

看到這個話題我突然想到了北京地鐵，我想在地鐵高峰期的時候，大家都有過身不由已的感受吧。換言之，既然是軟體依賴的還是硬體本身，硬體本身是存在上限的，所以從決策層角度來看，必然要考慮到成本與收益比的問題。準確的說，在正常併發下，新浪的後臺肯定是沒有問題的，只是由於突發事件導致一下子訪問量激增，資源不足導致出現問題。

另外一個維度，我想到了亞馬遜，現在公有云的老大非AWS莫屬，AWS的出現就是因為傳統的架構無法滿足黑色星期五的需求，而如果單純為了黑色星期五投入過多的硬體資源又會造成極大的浪費，所以AWS雲計算架構才應運而生。

據我所知，新浪微博已經在使用雲計算的彈性架構來解決自身併發性的問題，一方面可以有效緩解突發時間下的併發響應能力，另外一方面，也降低了不必要的成本投入，價效比最高。

歸根到底還是業務場景不同導致的。

對於淘寶等電商平臺而言，他們都併發高峰是可預測的，比如一年一度的雙十一，併發高峰肯定會在這些活動期間到達。所以我們可以看到，電商平臺在活動之前就會開始調配伺服器資源，調整線上併發承載系統，迎接流量高峰的到來，往往打的是有準備的戰爭。

而對於想新浪微博這種社交平臺而言，併發高峰通常是未知的。可能是當紅明星的八卦，也可能是突如其來的天災人禍。熱點在365天24小時都可能發生，而平臺往往難以預估。尤其是，這類社交平臺往往有放大熱點聚集人群效應的特性，這就使得流量高峰來得又快又難以預計。

彈性化的系統和24小時的運維體系，是對這類場景的解決方案，但當遇到現象級的熱點時，也難免出現系統無法承受併發的窘境，這時只能應急地加機器來解決了。

高併發一直以來都是網際網路開發運維的一個重要課題，各大公司都積累了成套的經驗，然而業務的不斷髮展，也正為高併發系統提出更多的挑戰。