Re: [應用]北市疫喵接種預約系統一點看法

看板java作者 (pupu)時間1年前 (), 1年前編輯推噓1(1012)
留言13則, 4人參與, 1年前最新討論串2/2 (看更多)
※ 引述《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)來分散入口流量, -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.169.230.212 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/java/M.1625163820.A.1D7.html

07/02 10:08, 1年前 , 1F
好棒棒的做法,原來新北預約轉圈圈是因為開放時間不夠久,
07/02 10:08, 1F

07/02 10:08, 1年前 , 2F
平均流量太高,至於排隊系統,讓我想起6/7衛福部紓困網頁
07/02 10:08, 2F

07/02 10:08, 1年前 , 3F
排隊要排上一整天,你說的不會是這個吧,哈哈
07/02 10:08, 3F
紓困系統的需求量 跟這次打疫苗的登記需求 根本就天差地別吧 需要準備的規模本來就不同啊 不過確實 我的想法就是 不論是 紓困 還是 預約疫苗,在前面登記階段,要有多快 或是 多順暢地承受幅度 都只是感受上的好與壞 沒必要花過多的成本,在這方面做過大投資, 很有成就感,可以提高大家的體驗,但我認為這很浪費 像是 打疫苗,你前面預約速度再快,實際能施打的疫苗速度就這樣了 是要還拚多快,多順暢? 宣導大家分段進場不就好了嗎? 用上各種設備方法 去想辦法 讓大家瞬間在開始幾分鐘內登記完畢 恩...好棒棒 然後大家登記完畢,設備就放在那浪費掉了 少準備一點,讓大家分散登記不是很好嗎? 那些都是我們繳出來的稅金阿,不要隨便燃燒阿 又不是賣演唱會門票,可以賺錢

07/02 12:57, 1年前 , 4F
這篇的算法才有問題,定時開放的系統一定是剛開流量最高
07/02 12:57, 4F

07/02 12:58, 1年前 , 5F
即使不抓全部人,也該抓個高比例,不能用時間平均
07/02 12:58, 5F

07/02 12:59, 1年前 , 6F
新聞有實際數據,前5分鐘完成16535,10分鐘26800,半小時接
07/02 12:59, 6F

07/02 13:00, 1年前 , 7F
近4萬人,在開機瞬間流量一定超過萬人,用每小時5千一定爆
07/02 13:00, 7F

07/02 13:01, 1年前 , 8F
要平均流量要有別的配套措施,比如說一連進來只發號碼排隊
07/02 13:01, 8F

07/02 13:02, 1年前 , 9F
輪到排隊時段才用簡訊之類的通知,再上線接續流程
07/02 13:02, 9F

07/02 13:04, 1年前 , 10F
這篇還估高峰也不過25人/秒,16535/5分鐘都已經55人/秒了
07/02 13:04, 10F
確實 在要評估準備多少人數的瞬間流量,我不好抓人數 所以有點低估了 但我的觀點是沒必要為了這種事情 去追求一個 上萬人同時連線,也要順暢預約 不論是每秒25人 還是每秒55人 用一台 標準 web server+ DB server 應該就能順暢應付,真的不行 前面一個分流系統 另外 你的建議,讓我想到更乾脆的做法 根據行政區劃分流,看是要分時段登記,還是多台server分開登記 ※ 編輯: pupuliao (61.231.182.169 臺灣), 07/02/2021 15:33:14 ※ 編輯: pupuliao (61.231.182.169 臺灣), 07/02/2021 15:37:50 ※ 編輯: pupuliao (61.231.182.169 臺灣), 07/02/2021 15:38:17

07/07 07:50, 1年前 , 11F
多少錢,一堆人都只談技術不談錢
07/07 07:50, 11F

07/07 16:18, 1年前 , 12F
最近上線的 中央版預約系統 就接近這概念
07/07 16:18, 12F

07/07 16:18, 1年前 , 13F
先登記意願,後面再分批通知預約時間地點
07/07 16:18, 13F
文章代碼(AID): #1WtWWi7N (java)
文章代碼(AID): #1WtWWi7N (java)