※ 引述《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日之前的才能预约吗?