簡單討論火車票系統后面的架構設計

[有點晚了，簡單寫寫，找時間再polish。另外，我們只談技術。]

簡單說，在線服務scalability有兩種方式，scale-up和scale-out。Scale-up追求單機性能，如高級硬件、異步架構等，而scale-out則用加機器的方法。Scale-out也是最簡單的方法，在規模不是非常大時很好用，也很容易解決問題，普通工程師就足以勝任。有很多現成的方法或模塊可以使用。 也就是說，很多時候通過加機器就能解決大多數問題。只要規模在一定量級下（通常的在線系統規模都不會特別大），我們可以先不考慮硬件故障以及自動運維。 但為什么很多時候系統還是崩潰呢？罪魁禍首就是請求的尖峰，10倍于平常的壓力是很正常的。普通模型到達性能瓶頸后，開始堆積請求（可能在web server，也可能在請求隊列，不過通常不會在CDN），吞吐急劇下降，延遲急劇上升，而隨著堆積請求越多，情況越糟，引起雪崩效應。而這樣的壓力通常不會持續很久，如果性能不急劇下降的話，一段時間后其實也就能把請求都響應了。 為10倍壓力而準備機器是不合適的，我們需要有辦法能扛住瞬間壓力。這時候架構設計主要考慮的問題，也就是我上個weibo所說的，如何保證極限情況下的穩定吞吐。有很多種辦法，分級隊列、請求調度、延遲截斷、主動拒絕等等，這些都有助于幫系統度過艱難時刻。具體的做法，就不在這里討論了。 當然，我也并不是說這個系統是非常難做的，因為可以有很多種做法，如普通文藝、高級文藝等，:)。如何用軟件架構的方法來實現scale-up就很困難，做得好與不好可能性能差異能達幾倍到一個量級。但對于普通公司來說，直接scale-out是最合適的，規模不大時多一些機器也不會對成本產生太大影響。但關鍵的是，要注意如何處理峰值壓力，提供極限情況下的穩定輸出。也就是說對于普通在線系統，即那些transaction-based systems，規模不太大，只是可能有海量的用戶請求。只要在設計時注意極限情況下的穩定輸出就可以了，實現的工藝水平高不高，差別只是機器多少而已，通常看不出來。 對于大數據量的系統，無論在線或離線（其典型代表就是搜索引擎），則又是另外的故事了。 繼續閱讀：《再談談火車票系統》

【本文首發于：林仕鼎新浪輕微博】http://qing.weibo.com/2244218960/85c41050330009xm.html

【關注百度技術沙龍】

?

轉載于:https://blog.51cto.com/baidutech/762993

總結

以上是生活随笔為你收集整理的简单讨论火车票系统后面的架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。