首先很高兴看到原PO发问
能够这样追逐更深入的技术，先恭喜你，离高手又更近一步了
我写程式要饭也好一阵子了，分享一下我从听说大流量很屌，想玩大流量，
到现在可以真正碰触到大流量一路的心得
在开始之前，先回应原PO的 抢票网站 例子
https://imgur.com/TON1Nid
以这张图架构图，我只能看出
1. request 分流
2. 静态资料缓存
这两个很直观的是可以解决一些问题，但这张图似乎少了什么东西？
以关键字喂狗 看到这张图
https://i.imgur.com/LMzKBpw.png
(from: https://aws.amazon.com/tw/solutions/case-studies/tixcraft/)
从这个架构图，我们可以再看出几点
(这里我只有单看架构图，不看其他资讯)
1. 静态 UI 有cache (最底下的 S3
2. 不管是 UI API (Tixcraft UI) 或是 public API(右边的API) 都有分流
3. public API(右边的API) 有cache
4. tranditional server 只能透过 tixcraft 进入
5. tranditional server 往 payment 是单向
6. pament 资料同步到 DynamoDB 供API取用
一开始我看不懂那个 tranditional server 的用意
为何要多绕一圈，把资料跑出去外面再绕回来？
照理说 Tixcraft UI 如果直接对 payment，完全在aws里面，应该可以更有效率
直到我看到这篇文章 https://www.ithome.com.tw/news/94531
文章里有一段是这么写的
“虽然邱光宗不愿多透漏云端购票系统的设计细节，不过，他表示，设计原则是采取多层
次架构，来解决数据库连线数过高的问题”
看到这边，我的理解是，他们是在不改变现有系统(tranditional server)的情况下，解
决突波性的流量的问题。我不确定他们实际上是怎么做，但可以大胆猜测最后的结果是在 Tixcraft UI 里面完成了类似 queue/cadidate picker 的行为，将先进(或是其他策
略)的用户转向原来就存在的系统。在现存的系统上进行付款，再将结果同步到 payment
和 dynamoDB 供查询
突发流量问题以机器的数量去解决，提高了同时在线的容载量
但这只是高流量的特定一种场景，他们确实解决了突波性的流量
因为订票性质的网站，买方的数量是固定的，且在一段时间内会持续被消耗
但如果今天场景是持续有这么大量的request呢？ 这系统会怎么样？
我想大概是在AWS 那一层被打爆(或是数量无限扩展)
直到 tranditional server 消耗速度可以跟上request数量
那么 为什么不把 tranditional server 直接放到 aws 上就好了?
我猜想是系统实作上没有以可扩展的架构去设计和实作
所以在有限的资源内，他们当时只能针对request进来的路径上先解决
而这确实解决了他们高流量的问题
那么，如果他们当时是可扩展的架构
是不是把 tranditional server 直接放到 aws 上就好了呢?
我相信不是这么简单
订票系统从直观上看来，跳脱不了排队、选座位、结帐这三件事(先不考虑复杂的情境)
排队基本上不能平行处理
(Tixcraft解决的是让大家可以同时在线的问题，而不是同时付款)
而 选座位和结帐 是可以的
就像电影院排队，一定不会只有一个柜台在卖同一个厅的票
而选座位和结帐这个行为的平行化极限，取决于订票流程(策略)的设计
该一次开放多少人来选票，这就是结帐平行度的极限
我想这个数量并不会大到必须要放到AWS去优化
所以拓元当时的解决方案是很合理且到位的
再来我们回到正题
我把你的问题拆解成以下2点
1. 怎么取得相关知识
2. 怎么活用在实战
在说明这2点之前，请容我先给你一个反馈
原PO文里说到的那些粗糙观念，要把它磨到发亮
例如
“hash function因为返回的是index，所以在查找资料上非常快”
提问:
hash code 会不会重复？ 重复了会发生什么情形？ 重复时，还能不能运作?
会怎么运作? 回到根本, 什么情况下要用 hash? 为什么用?
“每次看到thread，大概就止步于看到那种for loop 交叉印出不同函数的例子”
提问:
能不能无限制的开thread？ 极限在哪？ 怎么维护thread的数量？
thread的成本
是什么? 怎么降低成本? 怎么维护input 与 thread数量之间的关系?
回到根本, 为什么我的系统内要multi-thread? single-thread不行吗?
(redis/nodejs告诉我们，可以)
这些问题的答案都是高流量的基础
所以 yfr大大会说要一步步来，是有原因的
看到网络那些简单的范例，要先问这个技术存在的原因是什么？
它要解决什么问题？ 为什么要这样解决?
这些问题，在你之后面试时也会频繁被问到
这并不是大家刻意在洗脸，而是真的有影响的
如果你发现面试被刻意考这些，但是进到里面都没有看到这些应用
那我真心认为你可以走了，再找其他家
1. 怎么取得相关知识
怎么取得，又分两个问题: 知识、途径
- 知识
网络上一大堆，但是我想你真正想问的是，我该下什么关键字？
drajan 大大已经给出很多连结，可以从那里去找
或许你会问，这么多文章，我要从哪里开始看？ 这些技术我都用不到，真的有办法活用
吗?
我的建议是，真的不知道看什么，就听别人怎么说
在 drajan 大大分享的
https://github.com/binhnguyennus/awesome-scalability#talk
这里面有许多实战的talk，这些都是知名企业真正碰到的问题和解法
每一个talk一定会说到他们碰到什么问题，为什么要用这个解法
你看多了，自然就会开始回头去看各种基础原理
我另外推荐一个较轻松的方法
就是在 youtube 上找 youtuber
这里不是指程人频道那种轻松的 talk
而是要找更 hardcore 的，会解说原理的
而且必须是你觉得够轻松，愿意且看得下去的
youtuber 这么多，看到睡着代表不适合你
可能你程度不到看不懂，可能是说的不好，先换一个吧
例如我会看这位
https://www.youtube.com/watch?v=0vFgKr5bjWI
这个yt有许多篇已经改成付费会员才可看，如果你看过几篇觉得顺眼
强烈建议可以买订阅，会有帮助的
另外像我是开发java ，用的是spring
所以我也会订阅 spring framework 的频道
这个方法可以试看看
- 途径
你可以看到许多乡民们一直提到 需求/场景/主题
这是因为高流量这件事在不同系统上的难处都不同
发生在哪里(前端? API? consumer? DB?)，以什么样的方式发生?
不会完全一样
所以没有一个万用的架构，且牵扯到的观念太繁太杂了
绝对没有人可以跳出来跟你说该怎么做
你也绝对不要期待在工作上遇到有前辈会跟你说
一来是因为他们的这些观念都已经内化，对他们来说是基础常识，不觉得要特别说，顶多
是在code review时会说要注意的地方
二来是画著架构图时候的那个房间，没这些功力的人是进不去的
我自己看到白板上划架构的时候，都是发生在面试时我画给面试官看
所以你会发现一个事实
https://i.imgur.com/YLyjKel.jpg
开出高流量职缺的公司，通常都期待这个人会这些，最好也经历过这些
所以没这些经验的人，到底该怎么办？
答案就是：就像 yfr大大说的，打好基础知识，看talk学相关的观念
在面试时，表示给面试官说，这些我都知道，我就是欠一个场景给我练练手！
千万不要说，我会学。面试官只会OS: 你现在早该学会了
以我自己的经验，我在没有场景的公司，有想过这样分布式的场景，该怎么做
但实际上我并没有去实现，只是把他画出来，设想一遍
画得出架构，并且说得出来这么做的原因
也在之后的公司里面验证我的概念是正确的，因为我看到类似这样的场景
所以自己去学那些观念，并且假想场景并且设计是非常重要的
在高流量开发的当下，最重要的就是要有这些观念存在心中
在我的想法里，如果你的公司现在就没有这种场景
你也不用花时间精力去提要做什么高流量
一来是，可能没这个需求，会被当成麻烦人物
二来是你做错了，也没有人有能力指导你
一间公司的高度通常在你进去的时候就决定了
除非你持续看到进到公司的人一个比一个还要强
否则，我认为就是投身到真正有这种场景的公司
所以在我看来，最大的重点就是想办法找到这样的公司
通常有些搞不清楚状况(或是故意找碴)的面试官/猎头会问你
那你们公司没有高流量的架构吗? 为什么你自己不做高流量的架构?
我会这样回答: 没有场景，没有必要 / 我做了其人会看不懂，没能力维护
但是此时，如果又被追问，那么如果是怎样的场景，你怎么做
这时候，你必须要有能力可以分析问题，说出你的看法
就像我前面分析抢票网站的过程(一定会被追问更多细节)
2. 怎么活用在实战
所有的高流量，都不会跳脱一个观念，就是：快
所以在任何你让一个request处理过程变快的改良，都是一个活用的迷你场景
就以你问的问题 “getallemployee” API 反问你
如果现在场景是 monolithic 的情况下，你怎么让这个API更快?
这个问题可以有不同假设，所以有不同的架构
改良可以做在DB上，资料结构上
会这么问的原因是，在你看到的大型系统架构
有大部分是单机上碰到的问题的放大版
从 monolithic 到 distributed 的过程会有很多问题
例如当 employee 资料更新了，你怎么确保资料的一致性?
在 distributed 的场景，drajan大大已经解答了(认同+1)，如果你注意看的话，他说的
只是其中之一的解决方案
且他提到的 cache cluster ，硬要说的话，理论上也存在一致性的问题
(即便是时间非常短，或是没有这问题，看cache cluster实作或配置而定)
那么进一步，我们现在不看这个答案，
你能不能想出什么方法可以实现在 distributed 场景上？
之所以不要在网络上找到其他方案，是因为你加入这样的公司
势必要有能力面对一个场景，这场景可能是你网络上找不到的问题
你的前辈或主管会预期你有办法处理这种场景
我有看到 kvjo大大说到，通常大流量会有人负责做
不是资深的不会让你碰
我认同这个看法，但认同一半
大流量的基础架构确实让有经验的人去处理是最好的，
但是在架构出来之后，通常会伴随产出一套专用的framework，
在这个framework之下，即使没有经验，但有概念的人也能够知道是怎么回事
在这些基础下，可以更容易的学习到更多相关的经验
而在这样的基础下，你开发的东西就已经是分布式的架构
你开发的东西，就必须符合高流量的水准
开发的过程中，去注意多执行绪和重复消费已经是基本
所以加入一家有高流量场景的公司，是最重要的