https://booking.health.gov.tw/Home/TakeNum
网络上看到台北市疫喵接种预约系统顺利运行，也去看了一下，
试用了一下整个过程是：
1.首页(同意后选莫德纳)
->2.选院所(3个同意再Load时段Json)
->3.填资料送出(未真的送出)
发觉这系统没上云端，后台居然还是IIS 10，也没有提升到HTTP/2,
dig一下发现也没有用DNS做RoundRobin,
查了一下北市75岁以上统计人口约19万多，
表示单一IP可能要同时承受上万人的殴打(×)点击(○),
北市府的资讯处真的厉害的打击手。
想说如果是一般规模不大的公司要如何解决，盘点一下设计思路，
1.不能时间一到就让所有人一拥而上。
2.毋须登录。
3.写入永远比读取慢很多，写入数据库则是更慢，档案则好些。
4.太多人选择同一时段造成的超额处理。
我想大多数解决人多的想法,就是多架几台(load balancer)来应付就好,
频宽不是问题,电信商调整一下就好。
首先第一要务是解决"单一IP可能要同时承受上万人的点击"这件事，
当然有钱的买一台高级的负载平衡器，用硬件来解决，
规模不大的公司出不起这个钱，所以我的做法是最前线就是
一台稍微好一点的机器架上一个 Linux Virtual Server(LVS)来分散入口流量，
LVS后面就接上2~3台Nginx做反向代理(装在VM上做Load balancer用)，
再来就是架上多台Web Server(也是在VM上)。
大概架构如下(我会把实体机接在同一个Hub上,减少网络传输时间,
同样VM也是分散在不同的实体机)：
(1)×LVS(实机)→(N)×Nginx(VM)→(X×N)×Tomcat(VM)
因为上述所有的机台都是用Linux，所以自然必须重新调整内核参数,
以应付大量Request,(可以用Nginx并发优化找到一堆内核调整的文章)。
1.防止时间一到所有人一拥而上，最好的策略，就是阅读测验：
例如阅读需知,点选同意与先回答一些问题，最后再跳出视窗再确认一下，
造成每人的时间差异,分散一下开局的压力。
2.毋须登录,让Web程式变成Stateless，也就是request资料,
无论送到哪一台Tomcat都一样,万一需要用户登录，最简单的方法就是导入
redisson-tomcat，把Session资料在Tomcat间共享，或都非Tomcat系直接导入
Spring-Session，但是就是要额外多架一台redis server
或是使用Hazelcast Library。(我的建议是redis)
3.最终资料总是要写入数据库的,不管怎么Tune,concurrent connections
最多也只是调整到1、2干个，查询(快且占大多数)+写入(慢很多)，
我觉得较好的策略就是快取(读取结果)+JMS(数据库缓写入)，
当用户取得资格,最好的方式就是登记资料写入redis当快取并
抛给JMS慢慢写入数据库,完成再发短信。
4.最后要说的就是Race condition的问题,举例多个人同时看到剩一个
名额时,最简单的方式,就是开sequence,但缺点是每个院所都要开一个,
也有人用trigger避免超过,但人一多都容易引发DB overwhelming。
更好的方式是使用redis的atomic做取号,超过就叫人重选一次院所。
虽然推荐redis,只是因为网络上都说好,我实际上只用Hazelcast实战过,
这里不得说一下,Redis虽然本身虽然有Transction,但她没有ROLLBACK，
如果要达成XA，必须引入redisson做为redis的Client。
另外还有一些改善点,Nginx支援HTTP/2与Etag，
常用的css,js,与图片,连到首页时就用同一个连线送出,并且就加ETag,
下次就客户端就无须重新加载这些Resources。
北市预约系统的jquery-3.3.1.min.js首页出来时未加ETag,
选医疗院所第2次才有ETag
然后重选医疗院所时ETag没有发挥效用,又再一次加载。
不知道是不是IIS的问题，