Skip to content

結論

Jump to bottom
乾太 edited this page Aug 23, 2021 · 2 revisions

結論

整篇研究主要在探討以往網頁應用程式接收到請求就寫入資料庫時，如果系統無法負荷瞬間人流量所導致的問題，如果碰到資料庫寫入時，這個問題會更加明顯，好比說搶課系統、整點售票系統、購物節線上購物 ... 等等，在系統的設計當中，系統最先接觸到的會是 HTTP 請求(Request)，我們最需要保護的是最底層的那個資料庫(Database)，根據水桶理論[3]我們應該防止 HTTP 請求(Request)直接摸到最底層的那個資料庫(Database)，因此才有隊列(Queue)上的改善。

水桶理論，目的是在保護最下面的 DB
https://hackmd.io/@LaravelTaiwan/Conf2019

\     HTTP Request     /
 \         CDN        /
  \       Read       /
   \      Queue     /
    \     Write    /
     \  Database  /

隊列(Queue)目的是將原本要直接向資料庫(Database)新增資料的事情，轉給隊列(Queue)去處理，如果直接讓資料庫新增資料的話，那麼處理速度太慢了，量多系統無法負荷時，系統就會面臨到過載問題，所以隊列(Queue)允許你將一個耗時的任務延遲處理，來加快系統的回應速度。

另外使用 Redis 快取服務，也是為了盡量減少 HTTP 請求(Request)直接觸摸到資料庫(Database)的機會，轉而從 Redis 快取去尋找原本應該要從資料庫(Database)查找的資料，除非 Redis 快取裡面沒有，才會轉往資料庫(Database)去查找，並且將資料存入 Redis 快取當中，但是這也會面臨到另外一個問題，那便是雪崩效應(Avalanche effect)。

雪崩效應(Avalanche effect)

如果在 Redis 快取當中還沒有要查找的資料時，系統會直接向資料庫(Database)去尋找資料，在這個尋找資料的過程當中，如果也有其他尋找相同資料的請求(Request)，那麼這些請求也會因為在 Redis 快取當中還沒有要查找的資料，而轉往直接向資料庫(Database)去尋找資料，也就是說所有的請求在 Redis 還沒更新資料以前，所有的請求通通都會直接觸摸到資料庫(Database)，造成資料庫的過載，進而導致資料庫的崩潰，因為資料庫的崩潰，再導致快取的崩潰，最後是網頁應用程式的崩潰，這一層一層的連帶關係被稱之為雪崩效應(Avalanche effect)，為了避免這樣的憾事發生，於是便有人提出了微服務(Microservice)的解決方案[4]。

Clone this wiki locally