因為對資訊系統有興趣，基本功練好了就會對一些聽起來很有學問的技術感到興趣，譬如說當選課系統塞車，或線上遊戲玩家爆滿時，就會有「加開伺服器」的動作。同樣的程式拷貝到多台電腦執行是很容易，但是外面網路傳來一大堆工作，必須平均分配給多台功能一樣的電腦，處理完的結果還必須匯集到某個資料庫伺服器進行整理回應，這就是大學問了！這種專業級的技術當然一般書籍裡面找不到，最多是課本等級的書會提一下原理，所以實作的細節就讓我很好奇了！

以前即使可以試著寫程式，也因為沒有爆量的網路資料(要求)可以驗證我寫的程式是不是真的有用，現在可好了！正在做的嘉義市警局路口監視器車牌辨識這個系統目前就必須解決這個問題！之前運轉時已經預知一台伺服器應付不了兩百多台監視器傳回的照片辨識，所以買了七台伺服器，將各路口監視器平均分配給七台伺服器，就是一台照顧約三十台監視器。結果發現各路口交通流量落差很大，號稱規格相同的伺服器處理效能也有落差，運氣很差的是：我們最快的電腦資料量最少，最慢的電腦卻分到最大的流量！所以一到交通尖峰時刻有兩三台伺服器就會嚴重塞車，這會讓系統變得不太「即時」，如果一輛搶案落跑的車子經過監視器，可能要兩個小時後才在資料庫中出現，這就不太好用了！

我最先想到的解決方案是：統計每日或每週各測站的流量，依據流量重新分配給各個伺服器。但是緊接著發現這個辦法不好！或許因為嘉義市也是前往阿里山觀光區的必經之道，每到周末假日其實塞車的伺服器會不一樣，甚至早上上班與晚間下班時段會塞車的伺服器都不同！還是無法讓所有時間都不塞車。

這讓我想到了去大賣場購物結帳的經驗，如果每個客戶，就是每個測站要回傳照片時，可以像我們在賣場結帳一樣，直接看到哪一個結帳台人比較少就去排隊，這樣一定會最有效率，最快結完帳回家！所以啦！我設法讓伺服器程式將辨識完的資料回傳資料庫網站時，順便報告本伺服器目前排隊等待處理的照片張數；這樣一來資料庫網站就會有目前塞車狀況的整體數據，然後每個監視器測站每隔一段時間就來參考一下，決定要將照片傳給哪台伺服器處理，當然是找最不塞車的那台囉！

原則如此，但是程式系統包括資料庫結構要處理的細節還不少，昨天趁假日清靜的時間將整個系統都改建了，目前真的可以達到動態平衡，每台伺服器待處理檔案數隨時都差不多。只是有點不幸，我改客戶端程式出了一點錯誤，又太急著安裝了一百台左右，結果這些錯誤讓我的誤傳照片遽增，流量比正常時多很多倍，到晚上才陸續修正完成，到今天早上各伺服器還在陸續消化這些垃圾。不過也正好可以測試整個系統被爆量資料考驗的情境，所以就不手動去刪除這些垃圾資料了！希望今天以整體七台伺服器的能量，可以一邊清垃圾，也漸漸趕上進度，讓整個系統變成不塞車的即時系統。