※ 引述《kentyeh (kent)》之銘言：
: https://booking.health.gov.tw/Home/TakeNum
: 網路上看到台北市疫喵接種預約系統順利運行，也去看了一下，
: 試用了一下整個過程是：
: 1.首頁(同意後選莫德納)
: ->2.選院所(3個同意再Load時段Json)
: ->3.填資料送出(未真的送出)
: 發覺這系統沒上雲端，後台居然還是IIS 10，也沒有提升到HTTP/2,
: dig一下發現也沒有用DNS做RoundRobin,
: 查了一下北市75歲以上統計人口約19萬多，
: 表示單一IP可能要同時承受上萬人的毆打(×)點擊(○),
這算法有點問題吧
台北市第一輪疫苗 9萬劑，第二輪6萬劑
第一輪 給兩天共18個小時登記 平均每小時 登記5000個人
平均一秒1.3人
這種等級的要求 根本不算壓力吧
至於你說前台被打死，頂多前面增加一個 排隊系統就搞定了
不過看來市府用更省事的做法，只在上班時間開放，有問題MIS 跳下去處理
被打死了就重開機 把大家踢出去 然後重新排隊
根本沒必要為了這種小事 搞那麼複雜的系統，簡單快速上線 ，反正打疫苗速度就這樣
預約系統跟得上就好
打疫苗這種事，又不是搶物資，政府準備的疫苗 就差不多 符合資格的人數
根本不需要跟大家搶，我們家收到市府通知時，我本來想 那我去最後一個時段不用預約的好
了，不過我爸是順手預約了，9萬人只要不要同時一起上 根本不是啥問題
就算同時在第一小時上限，也不過就每秒25人 還好吧，沒啥壓力吧
我只是單純得你想得太複雜了，又不是要賺錢，付出那麼多成本在這裡做啥
再說了 現在還有人想等BNT，想打更好的疫苗 一堆人不敢打，
: 北市府的資訊處真的厲害的打擊手。
: 想說如果是一般規模不大的公司要如何解決，盤點一下設計思路，
: 1.不能時間一到就讓所有人一擁而上。
: 2.毋須登錄。
: 3.寫入永遠比讀取慢很多，寫入資料庫則是更慢，檔案則好些。
: 4.太多人選擇同一時段造成的超額處理。
: 我想大多數解決人多的想法,就是多架幾台(load balancer)來應付就好,
: 頻寬不是問題,電信商調整一下就好。
: 首先第一要務是解決"單一IP可能要同時承受上萬人的點擊"這件事，
: 當然有錢的買一台高級的負載平衡器，用硬體來解決，
: 規模不大的公司出不起這個錢，所以我的做法是最前線就是
: 一台稍微好一點的機器架上一個 Linux Virtual Server(LVS)來分散入口流量，

好棒棒的做法,原來新北預約轉圈圈是因為開放時間不夠久,平均流量太高,至於排隊系統,讓我想起6/7衛福部紓困網頁排隊要排上一整天,你說的不會是這個吧,哈哈

這篇的算法才有問題，定時開放的系統一定是剛開流量最高即使不抓全部人，也該抓個高比例，不能用時間平均新聞有實際數據，前5分鐘完成16535，10分鐘26800，半小時接近4萬人，在開機瞬間流量一定超過萬人，用每小時5千一定爆要平均流量要有別的配套措施，比如說一連進來只發號碼排隊輪到排隊時段才用簡訊之類的通知，再上線接續流程這篇還估高峰也不過25人/秒，16535/5分鐘都已經55人/秒了

多少錢，一堆人都只談技術不談錢

最近上線的 中央版預約系統 就接近這概念先登記意願，後面再分批通知預約時間地點

直接開google表單登記好了 最便宜 XD

g表單確實是一個好方法,剛剛疫苗系統已經進不去了,新聞說是6千在線/分,實務上並非卡關重開機即可,因為灌爆系統的這些人不會因為重開機就等下再來,重開還是有可能立即再被灌爆一次

疫苗系統其實分成登記意願+實際預約，登記意願看起來只是最簡單的身分證字號+健保卡號DB比對，做完也只是塞DB而已實際預約那邊身分認證比較嚴謹，還串健保局系統就被打爆了原本設計就是登記意願=排隊，可打了才通知上預約系統可是把兩個功能放在同一頁，造成一堆人去試預約功能預約功能應該直接做成不公開，收到簡訊/email才知道網址才滿足原本設計目標。就算是公開頁面至少也要先多加一道簡易資格確認擋掉根本不符資格亂試的人https://i.imgur.com/TCaqw8o.jpg今天剛開時原本只有左邊那兩個，都是接健保局系統後來新增第三個身份證字號+健保卡號，就是跟登記意願那邊一樣，資格不符就直接擋掉，就沒被打爆問題

真的就是一堆人 跑去打預約系統 我爸媽就是我跟他們說可以去填意願了，他們填完意願 就跑去登記預約，搞不訂 打電話問我為啥....我就說.....跟你說填意願，預約那邊 不是寫了 12日之前的才能預約嗎?