如果是你鐵道部12306網站架構師，如何設計網站的軟體架構和硬體系統架構

http://www.cnblogs.com/aigongsi/archive/2012/09/17/2683656.html

鐵道部新客票系統的設計（一）

鐵道部新客票系統的設計（二）

鐵道部新客票系統的設計（三）

__________________________________________________________________________________

http://www.oschina.net/question/88671_35944?sort=default&p=1#answers

用實際情境來表達的話：

1、售票廳不允許一直站在隊列的前面跟售票員交談，交談超過一定時間，你會被強制趕出隊列，解決重複重新整理的問題（如果重複重新整理，系統僅給出等待介面）

2、多開售票視窗（這拼的就是伺服器叢集的量級了，如果要支援上億的人同時購票，想想需要多少視窗。，通常一個購票的事務流程需要數秒的話，任何單純的叢集都解決不了即時的問題）

3、按照目的地，進行分地區限時購票，把1天24小時分成48份，每半個小時對應一個省級行政單位，通過行政規定把顧客分組，提高叢集效率。第二天重複該流程，限時表提前公布。

另外，電腦系統不能用簡單的加法來計算瓶頸，一個省試驗能使用，不代表格服務器量*40就可以同時支援全國了。

首先，我要否認一些看起來合理，但實際上根本就沒必要的最佳化方案：

1. 前台資料最佳化與壓縮
如果處理前台網頁資料的伺服器數量不夠，或者壓力太大，導致開啟網頁慢，載入網頁元素的速度慢，那麼就需要對前台資料進行最佳化和壓縮。但是，開啟首頁，從HTML檔案，到圖片，甚至驗證碼，差不多都是瞬間開啟（電信、教育網、聯通和網通已測），因此，前台那點文本資料，有什麼好最佳化的。當然，最佳化也可以，但問題的關鍵根本就不在於前台這點文本資料。

2. 對資料庫使用緩衝。
說這話的人，得去弄懂什麼叫電子商務。這種東西又不是微博這種ACID可以忽略不計的東西。電子商務的業務處理，需要高ACID，目前，鐵路訂票系統也就是因為需要保證高ACID，才導致了今天這些問題。然而，一些人居然希望使用緩衝，這種會導致ACID降低的方法，去緩解壓力，顯然，他們沒有意識到，這種設計，連需求都違背了，還談什麼最佳化。


這幾天，我跟幾個理論性強的導師以及有多個大型項目經驗的朋友，一起討論了這個問題。我們得出了一個結論：目前購票系統的瓶頸，在於ACID的實現關鍵：鎖。由於鎖具有一定程度上的硬體獨佔性，以及過程序列化等特點，加上目前通用的資料庫產品，會有內在的鎖的升降級帶來的開銷。這種開銷，再乘上國家級的業務量，就造成了，即使是使用目前效能最強的大型主機，可能也扛不住這種對鎖的使用需求。

要真正解決這個系統中鎖的問題，在數量級上提升鎖效率，就目前來說，是不可能的，除非未來的電腦結構或組件發生革命性升級。比如，就查詢餘票操作來說，用戶端的每一個查詢操作，服務端都需要一次相應操作。這種模式，反應到現實世界中，那就是，在售票廳裡，一個人需要擷取票的情況，售票員都得回答一次，因此有多少人，售票員就得回答多少次，顯然這是一種低效的方法。然而，現實中的實際情況是，所有人只需要看火車站大公告板，就能瞭解到票的情況，這種模式，在電腦中就是，服務端一次廣播資料，所有用戶端都可以擷取資料，但是，目前電腦以及網路硬體中，不存在這種裝置。在未來，可能會出現一些基於光或聲波來進行同時資料廣播的裝置，但現在討論這種裝置顯然沒什麼意義。

雖然如此，但我們還是討論出了3個小方案，可以線上性層級上提升鎖效率。方案如下：

1. 由於火車票這種資料的結構具有單一性，因此，每次業務處理，鎖的使用次數並不多。但是，如果使用通用資料庫軟體，則會帶來記憶體的額外的鎖開銷以及別的開銷。所以，我們需要把火車票這個資料庫“抽出來”，單獨做成一個C/C++的專門資料庫軟體，這樣就可以免除使用標準資料庫軟體所帶來的額外的鎖開銷以及別的開銷。

2. 盡量把票的資料，分攤到不同的伺服器上。這樣做，可以讓每台伺服器的鎖的開銷盡量小些，並且保證同時能有盡量多的硬體參與鎖的運算。比如，把一列火車的車票，分攤到10台資料庫上去。但實際操作中，具體怎麼分攤，我們認為，這個要根據壓力來計算，平時壓力很小的時候，也許1台伺服器可以同時處理多輛火車的票的資料，但春運期間，1台伺服器也許只能同時處理一輛火車的一小部分車票。計算壓力，可以人工統計，然後修改分配方案；也可以基於一些簡單的策略，加上機器學習，來實行機器自動化統計並修改分配方案。

3. 由於運力問題，火車站所提供的火車票的數量遠遠小於前來購買的人的數量，並且，在整個購票過程中，查詢的次數占的比率最大，因此，在使用系統的整個過程中，是讀次數多（查詢次數多），寫次數少（購買到火車票次數少）。所以，資料庫可以做成對讀操作進行負載平衡的叢集模式。這樣做的話，就可以加快查詢速度，然而，寫速度會稍稍降低，但這個降低顯然值得。