我是沒有參與訂票也沒有看相關的新聞報導

個人比較贊同 fillano 大的回答
就資料庫而言給定 sequencial 欄位或是 identity 欄位即可輕易抓取前 100 筆記錄

程式在進入的頁面上，設計先取得目前資料庫中已有多少筆記錄，超過 100 就就導向「謝謝再聯絡」的頁面，根本不會寫到資料庫。
如果同時間取得的筆數小於 100，那在submit之後由程式去控制，回應給程式的 nbr 超過 100，就導向「謝謝再聯絡」的頁面，這樣就能夠控制100張票，不需要 Lock不Lock Talbe或Transaction的問題，由資料庫自行 Handle 即可

要不要控制170萬人次／秒的點擊？我想華航本身或委包的廠商可能也沒有想過這個問題

而如何處理170萬人次／秒的點擊而網站不掛點？只要 Web Server 與其硬體等級夠強悍加上 load balance 機制去分流（不過前提是 load balance機器要能撐住），瞬間流量的問題，只要華航與 ISP 協調過，應該不是問題

唉!這真的只跟軟體有關嗎?看得出來你真的跟IT槓上了

這件事情讓我想起Server 2008的上市發表會的實境秀
想必華航程式開發小組，沒有事先模擬網站被塞爆的情況；而硬體或模擬技術小組沒有馬上插上刀鋒或是利用Hiper-V提供新的站台服務頻寬。
結論就是，那只有在上市發表會會玩，現實環境，就讓他掛吧。
但是，秒殺一百多張票，只能說是神奇，有沒有買到的人出來說說他是如何中此樂透的。

請設計線上遊戲的團隊來規劃華航的活動如何？來個百萬人圍城戰奪機票的遊戲好了...

"在訂票的午夜12點左右，華航網站創下瞬間170萬人次點擊"
1.如何控制170萬人次／秒的點擊而「只」賣出100張票？
2.如何處理170萬人次／秒的點擊而網站不掛點？
3.如何將網站伺服器的流量上線從5萬提高一倍為10萬？
我假裝很認真的討論這件事好了，先不討論軟體工程，我們從基礎建置開始。
瞬間170萬人次點擊，假設網頁的大小是100K(現在還有人做這樣小的網頁嗎?)，瞬間的流量是1700000x100K=170000000K=17GB的流量換算成網路流量還要x8 = 136G bps的流量。
不知道華航的網站用哪一家的ISP，很讚!
136GB的流量假設有設備處理，後面的網頁伺服器不管是加速器或是主機，數量一定很可觀。我看不用到軟體設計，基礎建設就做不下去了。
我直接認輸，沒有能力。 汗........!
重申我沒有說"做假"這件事。

小弟的看法是，瞬間要 170 萬人衝進去，這如 vincent118 守護神所說的，這…ISP 哪家有這個能力，所以小弟覺得…那應該是他們 MIS 的人回覆主管，在那段時間裡面 (Maybe 半個小時) 的人數流量。或是他們 MIS 把 Web Session 算成一個人頭，但通常一個 Web 畫面 Request 時，會造成很多的 Session 出現..

1.如何控制170萬人次／秒的點擊而「只」賣出100張票？
要達成只有一百人可以訂票，這用 SQL Server 本身的 Transcation 就可以達成了，資料庫在處理這方面還算強，畢竟也【只需處理一百筆】，雖然 Request 很多，但資料庫在一百筆完成後也沒有再做啥事了。

2.如何處理170萬人次／秒的點擊而網站不掛點？
不過多數網友都發生無法進入購票專區 (有這句話，網站的部份應該是有做分流處理)，或是出現系統無法提供服務的訊息 (而這句話是指還未分流前就塞住的狀況)
所以要不掛點，只有加大叢集服務，做硬體分流才有機會

小弟的認知很淺，從這個事件，小弟覺得軟體面似乎還好，反倒是硬體的承載與分流反而是重點。

小弟也重申我沒有說"做假"這件事。但他們報的數據資料 170 萬人次是【多少時間內造成的】要看他們的 MIS 怎麼報給主管...

1.如何控制170萬人次／秒的點擊而「只」賣出100張票？
資料庫的stored procedure + transaction
2.如何處理170萬人次／秒的點擊而網站不掛點？
雲端運算，不過比較好奇1秒170萬人次是怎麼算出來的？是看apache log嗎？如果是webalizer裡面的hits，加上每個人開好幾個browser重覆reload，實際人次應該還要打好幾折
3.如何將網站伺服器的流量上線從5萬提高一倍為10萬？
雲端運算

看pchome的新聞，大多數的人被系統踢出來，應該只有極少數的人能進入系統執行訂票的動作

網頁A:
前面100名的User,給予編號後直接導向另一台使用不同網路的Server(網頁B).
101名以後的,直接回覆"謝謝光臨,明天請早"
中間不使用資料庫或硬碟檔案.全部在記憶體處理.

網頁B:
判斷編號是否符合規則,進入訂票程序.

那100名User中間如果中斷或資料不完整, 算User自己棄權.
反正是賠錢賣,沒有真的達到100名完成訂票也沒關係.

我覺得最大的可能是，他們的系統也沒考慮那麼多（不管有沒有做lock、transaction、store procedure、cache、queue），反正就用最後存進資料庫裡面的資料做判斷，只取前一百筆，不管實際上是怎樣先來後到、或是在哪個環節拖到、伺服器的覆載是否均衡、線路覆載是否均衡等等。反正在系統裡做掉，沒人知道公不公平，他們自己也不知道。

這樣進來的request就拼命寫入資料庫，之後有沒有訂到，就讀取資料庫看看是第幾筆來判斷，中間過程一律不管，只看結果。（他們應該是用一個新的table等在那裡來處理這種特別的訂票吧？）資料沒寫入？中途負載過大？等等，那就明天再來。

弟曾任職於某旅遊公司，該公司經常辦一元火車票啦，一元飛機票的活動。
這種活動會強烈衝擊Infrastructure，如果基礎不夠強壯，軟體再好都沒有用！

1.如何控制170萬人次／秒的點擊而「只」賣出100張票？
只要是夠強壯的SQL Database，要控制只賣100張票是輕而易舉。

2.如何處理170萬人次／秒的點擊而網站不掛點？
這個數值應該是Total的人次，而非Concurrent的Session，不過估算起來也是相當龐大的流量了。

以下八項的負載能力都必須仔細評估，而且必須平衡！
其中一個環節很強，但是某個環節很弱，整體還是很弱！

1.網站頻寬大小？
2.防火牆Concurrent Session Limit？
3.應用系統負載平衡設備的Concurrent Session Limit？
4.多台網站伺服器的負載能力？
5.多台應用伺服器的負載能力？
6.資料庫系統是否能夠承受如此大量的交易量？
7.SAN Storage I/O的速度？
8.Switch Performance是否足夠？

以上這些項目都是環環相扣，我想華航應該沒有做壓力測試吧！

3.如何將網站伺服器的流量上線從5萬提高一倍為10萬？
這個部份用軟體來做，還是得有適當的硬體來搭配。
此外花錢做好基礎建設，軟體就不用這麼費工，基礎還是很重要的！

170萬/次! 以我程設師的立場看待,這是不可能的,怎麼算機票/位不可能那麼多.以台灣環境來看,訂票需求量也不可能那麼大.一天用線上訂票方式有辦法到幾萬張就不錯了.所以這應該是網站遭受攻擊.所以要請網管去分析流量來源,在去找因應對策,而不是頻寬不足,買頻寬,硬碟不足買硬碟的方式,這樣根本不能解決問題.

感覺是有人用連點程式吧...
或是用按鍵精靈規則寫好一直點...
170萬人次咧...
真正的想要去買人的人不多吧...
比較多的是圖利者吧...

為了短暫有限的銷售商品提供大量的服務資源，本來就不是合理的行為。因為投入成本不會大於預計收入，所以就算事先知道一定會爆量也不會採取大幅的改善行動。

基本上這類具有爆量特質的網路銷售活動，本就不應該在標準系統上採取定時開始搶奪的模式，因為資源的有限性是很難避免的。

頻寬、硬體、軟體等方面不外乎就是尋求加大、加快、分散負載來解決。已經有很多人回應解決方式，但是應付短期需求你能夠投入多少。

要迴避機器人軟體的問題，不要在標準系統上處理，應建立新介面且越晚發佈越好。

時間分離也是解決方向，所以建議採用其他的銷售模式例如先登記後抽籤或者是競標來分散流量。不過這要企畫人員能夠理解接受才行。