Search for a command to run...
Articles tagged with #rookiejunior30
我們在上一篇文章中介紹了基本的Cache Aside Pattern，也補充了在Database 主從分離架構下可能造成Cache的異常，並一同介紹了：延遲雙刪 以及 CDC。 我們這個章節要來談談Cache還有哪些問題 快取穿透 (Cache Penetration) 定義 請求的資料 不在快取中，也不在資料庫中。 每次請求都會穿過快取，直接打到 DB，但 DB 也查不到資料，導致無法回寫快取。如果有惡意攻擊者使用大量不存在的 ID 進行攻擊，DB 會瞬間承受巨大壓力。 常見場景 惡意攻擊：...
在後端開發的世界裡，有一句至理名言：「沒有什麼效能問題是加一層 Cache 不能解決的；如果有，那就加兩層。」 雖然是句玩笑話，但道出了後端架構的核心思想——「以空間換取時間」。資料庫（Database）存放在硬碟，讀取速度慢且 I/O 成本高；而快取（Cache, 如 Redis）存放在記憶體（RAM），讀取速度極快但空間昂貴。 什麼是 Cache-Aside Pattern？ Cache 不會主動和 Database 溝通，所有的數據流動都由應用程式的程式碼來控制。 這就像去圖書館借書： ...
序 當系統架構逐漸成形、程式碼品質也趨於穩定後，下一個遲早會浮現的現實問題：撐得住嗎？ 也許在開發環境一切順暢，但一上線就開始出現以下情境： 使用者一多，API 回應時間明顯變慢 尖峰流量來臨時，資料庫 CPU 飆高、連線數耗盡 某個外部服務偶爾變慢，卻拖垮了整個系統 記憶體持續成長，最後只剩一句「Out of Memory」 這些問題，不是功能寫錯，而是系統沒有「緩衝能力」。 在 Module 4 中，我們將視角從「單一請求的正確性」，提升到「整體系統在壓力下的行為」。我們需要開始...
這堂課我們正式進入 - 結構型模式 的領域。 如果不把這「創建型」模式（工廠、建造者）搞定，我們很難有東西可以「結構化」。但現在我們已經學會怎麼優雅地產生物件了，接下來會遇到的問題通常是：「這個新來的物件，跟我的舊系統插頭不合怎麼辦？」 這就是 Adapter Pattern 的主場。 核心概念：轉接頭 從台灣帶了筆電（三孔插頭）出國旅行。 牆上的插座 (Client 期待的介面)：可能是兩孔圓形，或兩孔扁形。 筆電插頭 (Adaptee 被適配者)：兩孔扁型，一孔圓形。 問題：插不進去，無法供...
工廠模式 在 SOLID 的課程後，我們已經知道「依賴注入」的重要性：我們不應該在類別內部直接 new 依賴的物件。 但問題來了：「那到底誰負責 new？」 總得有人負責把物件生出來吧？如果到處散落著 new, 當需求變更時，我們還是要改一堆地方。 在Lesson 17 開放封閉 (OCP) 的時候我們有說道：利用策略模式來進行解偶，並利用”工廠模式”來決定策略的選擇(實作 實例化物件)，但當時對於工廠模式並沒有去詳細說明，這裡我們一起來看看工廠模式的相關細節。 核心概念：為什麼需要「工廠」 ...
關於LSP 接下來進到L了，這裡的L指的就是里氏替換原則 (LSP , Liskov Substitution Principle)，這是許多後端工程師覺得最「抽象」的一個原則，但它其實是判斷「繼承 (Inheritance) 是否被濫用」最重要的標準。 什麼是里式替換 (LSP)？ 「子類別 (Subclass) 必須能夠替換掉它們的父類別 (Base Class)，且程式的行為不會發生錯誤。」 簡單來說，如果程式碼依賴於一個父類別（或介面），那麼隨便塞一個該父類別的「子類別」進去，程式都...
