---

我覺得，光要做好 CRUD 就很不容易了耶，我想簡單談談 R 就好。

我們假設一下。

當你的 API response time 越來越高時，怎麼辦呢？

第一步可以先看看演算法和 db 有沒有調效的空間，演算法和 db 的調效就可以研究好一
段時間了。

如果調完了，還是不夠快呢？

那可以考慮分析一下你的資料，分出常變動和不常變動的，常變動的放在 db 沒問題，不
常變動可以考慮用 cache 來解決。

cache 可以考慮自已處理，或者找找適合的工具，然後要 cache 在本機還是弄個
memory 的 nosql db 呢？db 的話要 redis 或 memcached呢？



接著我們假設一下，你已經處理好你的 cache，也榨乾你那台 server 的效能了。

接下來要嘛升級要嘛加機器，升級總會到個物理極限就不談了，談談加機器吧。

加機器那問題就又來啦。（來不完乾）

如果你是三台、五台還好，一百台你總不可能要 client 接你 100 台機器吧，那就要瞭
解一下 load balancing 啦，lb 怎麼做和怎麼做好也是一門學問。

然後 100 台機器時，你總不會還要一台一台手動去更新程式吧，那怎麼自動部署呢，比
如用用 ansible 之類啊，也是可以研究的。

然後通常也不用到 100 台機器啦，瓶頸就又會變到你的 db 那了，那這時候要怎麼解呢
？可能可以做個讀寫分流啊，怎麼做跟怎麼做好也是可以好好研究。

光 R 感覺就講不完了，量一直衝上去挑戰就會一直來，頸瓶有可能出現在你系統任何地
方，你能承受越高的挑戰你的價值自然也越高。

學無止盡，回頭是岸。
不對，是加油，共勉之 ^^

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.150.53.122
※ 文章代碼(AID): #1R4dtgXT (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1527938538.A.85D.html