在專案開張那天提過，我可以正經八百討論一些專業的科技問題，今天就專業一次。
我的職稱是網站系統效能工程師，我知道它聽起令人不知所云，其實連我自己都不知道這個職稱真正的意義，不過美國不流行名片，可以拿出來危言聳聽的機會也不多。偶爾拿出來自己看看都會覺得有點迷惑。
這是我在矽谷行騙江湖20多年的吃飯本錢。不過說穿了就像魔術師一樣，台上表演的時候下面都是目瞪口呆，一攤開來看都是普通常識。今天就來分享一個普通常識，讓你可以滿足自己的好奇，同時了解世界上很多事情背後的簡單真相，也可以在茶餘飯後讓朋友羨慕一下你的專業知識。很多科技議題之所以會嚇人，都是因為一些故弄玄虛的專業術語。那些術語都是專家們怕你搶飯碗，才編出來讓你困惑的，很多人聽不懂也不敢問。
其實術語一旦拆穿了就最不值錢，所以不要被這篇文章裡面少數必須用到的專業術語影響到你閱讀的興趣。重點不是術語，而是背後簡單的邏輯。我會用老嫗都能解的比喻，讓菜場的阿公阿婆都能夠聽得懂。
是資源不足，還是遇到瓶頸？
網路會塞車只有兩種原因：一是資源不足，二是遇到瓶頸。這就跟高速公路塞車是同樣的道理，資源不足就好比高速公路線道不夠多，瓶頸就好比線道關閉，前者和後者沒有直接關係，所以瓶頸並不能靠資源解決。
網路世界的資源指的就是機器，所有機器都可以擴充，也就是花錢就可以解決問題。把這個比喻用在高速公路上，就好像你可以拓寬高速公路來解決塞車問題。所以資源像共產主義，只要有，誰都可以用，問題也就立刻迎刃而解。
只不過世界上的問題並不都這麼簡單。
令人迷失的是瓶頸，後面一半才是問題的重心。
如果塞車的原因是因為高速公路的收費站，你我都知道把上游的高速公路加寬完全於事無補。但很不幸地，這就是今天網路世界解決塞車問題的通則，因為他們根本不知道網路塞車除了資源不足，還可能有第二個原因，那就是瓶頸。
現在我們要借用2年多以前轟動台灣的江蕙事變，來繼續探討這個非常值錢的真相。所謂江蕙事變就是歌手江蕙封麥的臨別演唱會，秒殺預售票所造成空前絕後的網站大塞車。當時台灣的媒體只對黃牛炒票大肆報導，好像沒有人在乎一再大塞車的真正原因。所以一連換了幾家不同的售票管道都無一倖免，因為他們可能都以為這是單純的資源問題，而不停地增加機器。
秒殺所面對的瓶頸在於最末端資料庫內部的資料競爭，這句話是必要而邪惡的專業術語，看不懂是正常的，下面是我用白話文的解釋。
為什麼秒殺票造成網路大塞車？
幾乎所有的網站都分前端和後端兩大區塊，前端是用來處理指令，後端用來儲存資料。一般軟體工程師所寫的程式就是在前端的機器上執行，所以前端只不過是一堆專門執行程式的電腦，它只包含軟體程式，不包含資料。
資料通常是分開儲存在不同的機器上。這就好像你用Word寫一篇文章，Word本身的軟體是放在某一部電腦上，這就叫做前端。而你寫好的文章是儲存在另一部電腦上，而且這部電腦只儲存所有人各式各樣的文章，這就叫做後端，通常後端指的就是資料庫。
前端因為不含資料，可以無限制擴充加機器，機器就是它的資源。後端儲存的是資料——因為資料只有一份，會有競爭性；也就是當大家都爭先恐後去讀取同一筆資料的時候，你所面對的就是瓶頸問題。
下面這一段有一些必要的專業術語。不懂沒有關係，接下去會有很淺顯的比喻。
罪魁禍首都在 「資料競爭」
網站的資料庫都有非常強而有效的資料讀取能力。一般的伺服器每秒可以處理百萬次的查詢。當然這裡指的是隨機性的查詢，也就是每一個人讀取的都是不同的資料。
可是如果所有的查詢都是針對某一筆特定的資料，資料庫的處理能力就驟降百倍，而減到每秒一萬次。而且這些都只是 「讀取」 資料而已。如果要「改寫」 資料，流量又驟降100倍，淪落到每秒只有100次。原因是同一筆資料一次只能容許1個人更改。更改的過程中那一筆資料要加鎖，防止第2個人同時更改。
這也是全世界所有的資料庫都必須採用的保護措施，目的是確保資料的完整與真實，而且改變後的內容必須寫到磁碟機上才算數，不能留在記憶體內。所以這不但是單線操作，而且過程冗長。
查字典的比喻
假設一本字典有100頁。如果我把100頁通通攤開來放在一條很長的桌子上，我就可以讓100人同時查閱。不過前提是每一個人所需要查閱的字都是隨機而不衝突的。這個時候我的平行處理能力是100。
可是如果剛巧每一個人要查閱的都是同一個字，那麼我一次只能處理一個查詢，其他99個人就必須排隊等候─儘管我還有99頁處於閑置狀態。這個時候我的處理能力就驟減為 1，這就是查詢同一筆資料所產生的競爭後果，可是更糟的還在後面。
假如不但所有的查詢都針對同一個字，而且都還必須更改內容。那麼我的處理能力就降為0.01，因為改寫資料比讀取資料又慢了100倍。所以我們所面對的資料競爭瓶頸就非常明顯。電腦的處理能力因此跌了10000倍。這就好像所有車輛都指明必須通過收費站某一個特定的窗口，而且每一輛通過的車都要填寫一張表格。
回到江蕙事變
現在我們把整個流程套回江蕙事變。
當35萬人同時湧入網站購票的時候，他們首先進入前端指令處理區。每一個用戶用滑鼠點擊一次，背後就是一項指令。每一項指令都需要程式來執行。所以購票一開放瞬間就同時有35萬項指令同時湧入。處理票務的網站很可能早已枕戈待旦，有好幾百台前端伺服器待命處理這些指令。前面說過，這些都是資源，可以無限制擴充，所以這裡不會出問題。
假設這35萬人都很順利通過前段處理這一關，接著面對的是買票和付款。這裡立刻面臨兩個資料競爭的瓶頸：第一是買票，為了要知道能不能賣票給這一位用戶，資料庫必須先查閱是不是還有剩餘的票，如此一來是 35 萬人「搶讀」同一筆資料，速度立刻減100倍。如果還有票，就得扣除這一筆交易賣掉的張數，再把結餘重新在資料庫裡更新，這是「改寫」資料的內容，速度就再降100倍。
最後一個關口是付款。因為所有買票付款的對象都是同一個帳號，即使資料庫可以同時處理10000個帳戶還是於事無補。所有的焦距都落在同一個帳號上。更糟的是付款之後帳戶的結餘必須立刻更改。這又牽涉到改寫資料。回到前面查閱字典的比喻，這就像35萬人不但都要搶著查閱同一個字，有幸查到的人還必須更改內容，再把那一頁字典放回去好讓後面的人繼續搶。
所以我們可以想像這是一個上寛下窄的漏斗狀流程。
一般業界常犯的錯誤
由上面的例子我們可以清楚地看出秒殺塞車，是後端針對某一筆特定資料競爭搶讀，及反覆不停地改寫內容所造成。這才是真正的原因。可是由於塞車所造成的回堵很快就從後端的資料庫蔓延到前端的伺服器，最後一直擴散到網站入口。不明就理的人看到前端塞車就可能倒果為因，認定這是前端的資源不足，而拚命擴充資源增加機器，提供了一個風馬牛不相及的解決方案。
這就好像泰山收費站只能使用一條線道 （其他所有線道都空著卻不能使用），而且每一輛通過的汽車必須停下來填寫一張表格才能繼續行駛。這使得南下車道一直回堵到圓山。解決問題的決策者在圓山飯店，只看到圓山路段嚴重塞車，卻看不到塞車的源頭。所以認定這是圓山段線道不夠多，於是丟下大把銀子拓寬高速公路。
Photo source: Autoevolution.com
這些都是普通常識。同樣的情形用在日常生活，大家都能很精準地解決問題的根源。可是一旦進入網路世界，普通常識立刻變成值錢的專業知識，因為最大的差別是，網路世界是看不到摸不到的。網路效能工程師的職責就是要非常了解從入口到出口之間的全部流程，然後收集解讀所有的數據，找尋系統中所有可能存在的瓶頸，提供一針見血的解決方案。
這個市場在矽谷很缺人。Google和Facebook都在挖角，你若想改行靠這個吃飯也很值得鼓勵。不過拜託忍一忍，等我退休以後再這麼做。少一個魔術師搶飯碗可以讓我再多混幾年。
首圖來源：Pixabay
文字編輯：Wendy Chang
