NoQ Flash－RedSo的新產品
上年底旅發局搞的除夕大抽獎，成為了IT人茶餘飯後的話題。其實早在網站未上線之時已有人預言系統一定會出事。當時我不置可否，因為在此之前，李嘉誠基金會就和Google Cloud做了一個完美的案例，在短時間内用雲端技術將派錢也解決得妥妥當當，理論上大抽獎也算是普通的eForm，不會複雜太多。
系統最初採用SMS認證碼
但當看到系統要求SMS認證碼，事情的走向就已經註定失敗。One Time Password（OTP）是網上服務常見的2FA（Two-Factor Authentication），主要用作username／password以外的多一重認證之用，常見的SMS－OTP應用包括信用卡的3DSecure，消費者需要在既定時限內輸入由銀行以SMS發出的OTP，經過核實交易才可以作實。我們日常在網上消費應該對SMS認證碼非常熟悉，表面看來亦沒有什麼問題。
不過當OTP用在大流量系統時，事情就沒有這樣簡單了。記得幾年前大家都搶購iPhone的時候，Apple就推出了iReserve系統，消費者需要獲得SMS OTP才可以進入系統選購。由於沒有公開數據，估計以當時短炒iPhone的豐厚回報，大膽估計參與人數不會少於買演唱會門票，姑且毫無根據地假設參與人數為20萬人。還記得當時很多人都投訴因為遲了收到SMS而買不到iPhone嗎？
顯然SMS系統的throughput是有限的，20萬SMS並不是同一時間一起送出，就像排隊一樣，只有排得較前的人會快點收到SMS。
稍為看了一下其中一個流行的SMS gateway－accessyou，其服務列表中列明最快的delivery speed為20K－200K SMS/hour。
回到除夕大抽獎，對象是（全港在港市民+在港遊客）。根據旅發局數據：
2019年11月訪港人次為200多萬，本港居民按700萬計，這個大抽獎要應付的SMS量起碼也要百萬級計。就算一小時派送20萬SMS，一百萬個已經要花五個小時，除非登記時間提前幾天，否則要在抽獎當日收到SMS根本沒有可能。
系統最終改以email作為驗證碼
不知道是否SMS gateway公司打退堂鼓，後來系統最後改以email方式做OTP。不過，最後還是出現了與SMS一樣的throughput問題。
事實上Email－OTP比SMS－OTP還更難控制。Email服務由一個server送出，再由另一個server接收，這個連接牽涉兩個server的溝通問題。由於日常Email Spam問題非常嚴重，一般Email server在接收到郵件後都會有機制去擋格高風險的郵件。如果Email由非常陌生、甚至新註冊的Domain送出，基本上沒有機會可以送達用戶的戶口。在大抽獎時，服務採用了sendgrid派送Email，sendgrid本身是一個專門派送Email的服務，理論上sendgrid已經幫忙處理好上述的風險問題。
但sendgrid服務同樣有rate limit。 以全港大抽獎的規模來說，肯定可以輕易突破這個上限。以每分鐘10,000 request計算，send完200多萬個mail，最少要花上 2,000,000/10,000/60 ~= 3.3小時。不過sendgrid作為一個Email服務專家，資料到達sendgrid後，系統還需要再針對不同的收件server進行排程，及分派到不同IP的server發出，這樣才不會令sendgrid整個domain都被其他收件server列入黑名單。就當一切順利，接下來，當Email派送到收件server，收件方還會再做Spam and Phishing掃描，國內有些server甚至會對內容進行政治審查，只有在完成這些安全檢查後，郵件才會派送到客戶郵箱。
如是者，如果系統要求收到Email認證碼並且在限定時間內進行登記的話，技術上根本不可行。個人經驗，我的email OTP在2020年1月1日凌晨接近3時才送達，共延誤差不多9小時。結論，這種大流量系統應該避免使用OTP。
網上排隊系統
到了最近武漢肺炎橫行，市民減少外出，改為eCommerce購物，不少網站人流突然爆炸性上升，原來的系統根本無法承受，當中包括大品牌例如屈臣氏。重點防疫產品例如口罩及清潔液等，求過於供的情況非常嚴重，高峰時甚至引來過百萬人流。於是一個有效的網上排隊系統突然變得非常重要，這種系統可以將人流魚貫排好，按原有系統吞吐量，一個一個放行。這個服務好像實際到銀行櫃位的派籌系統或入場看演唱會時的鐵馬陣。但部分網上排隊系統在人流多的時候要求用戶等候幾個小時才可進入系統，而且就算耐心地等候，也不一定確保產品還有庫存，整個購買經驗並不理想。
我們相信網上排隊可以有更好的解決方法，一種更有效率，更公平，無論供求方都更便利的方式。於是我們開發了NoQ。
大流量系統之難
大流量系統之難在於數據庫，數據庫在寫入的時候必須確保同一時間只有一個寫入，才可以防止錯誤的覆寫。同時由於數據量大，如果資訊保安做得不好，所洩漏的客戶資料亦同樣巨大。
在雲端技術中，就算前端可以同時顯示資料給一百萬人閱覽，在下訂單要寫入數據庫時，數據庫的瓶頸依然存在。以Google Cloud的Datastore為例，rate limit是一秒一個寫入。在面對百萬級人流，如果沒有適當的處理方法隨時需要過百小時。將數據庫做Sharding（分片化）處理是其中一個有效的方式，但遇上幾萬人同時搶購同一產品，單一產品的庫存更新還是非常難做到的。所以NoQ乾脆就連數據庫都不用，那麼瓶頸也就消失了。
NoQ實戰
NoQ全名Not Only Queueing，基本上不是排隊系統，理解為No Queue亦不為過。如果說坊間的系統像鐵馬，NoQ就像是賽跑的終點線－同一時間會有很多跑手衝線，但每位跑手都有獨立的衝線時間，就算真的相差一個半個馬鼻，仍然可以分出先後，無須等待前面的人衝線才讓下一位跑手衝線。為確保數據安全性，NoQ自然配備HTTPS基本功能，確保客戶端與伺服器之間資訊的保密性和完整性。在此之上，所有數據在傳輸之前都會使用RSA和AES加密，確保數據就算中途不幸被截取，亦不會洩漏半點。
NoQ雖然面世沒多久，但已經做出了少許成績。我們利用NoQ配合Boutir掌舖，投入了人流最多的口罩搶購事業。幾萬個買口罩的名額，引來了10多萬人流，產生了幾百萬pageview，NoQ只用了短短幾十秒就派發完成，過程非常順利，獲得了不少客戶的正評。防止機械人、重覆拿籌等問題，我們也當是理所當然的加入了就不累贅了。本地知名搶飛專業KKFly 亦實測過就算使用程式方式都不能搶到名額。
RedSo作為Google Cloud的Premium Partner，NoQ使用了Google Cloud最尖端的Serverless技術，穩定性高，在我們內部測試中處理百萬級人流完全沒有問題。NoQ的應用場景很多，包括各式非常大流量的應用，例如投票、限時閃購、各種門票、比賽登記，當然亦包括大抽獎了。如果你的服務需要應付大流量人流，NoQ一定能幫你妥善解決。