查理工程記

前言 這是InterviewBit中Storage Scalabiliy第一題，設計一個快取系統。 我希望可以透過InterviewBit中的文章與題目，打開自己系統設計的視野，並且重裡面中得到關鍵詞彙，透過這些關鍵詞彙補足自己知識的不足。 其中會參考許多 jyt0532神 的許多文章 題目 替Twitter或是google設計快取系統，概念圖如下: 分析步驟 列出需求情境 估算 立定設計目標 深入探討設計方法 需求情境 需要多大的快取 我們的快取清除策略要如何 因為快取大小所以必須將舊資料刪掉 快取的寫入策略 Write through cache 當資料寫入時，同時寫入DB和Cache中 寫入因為需要寫入兩個系統(DB/Cache)所以有較高的延遲 Write around cache 當資料寫入時先寫入DB，當快取被讀取發現遺失資料時，再將資料從DB同步到快取中 因為讀取是從快取中讀取，但是在讀取時判斷到有新增資料沒進入快取，會有較高的讀延遲。 但寫和重複讀不會有特別的延遲 Write back cache 直接將資料寫入到快取中，在同步到資料庫裡 風險 - 畢竟快取是in-memory會有遺失風險 優點 - 高寫入效率(寫得快可附合的流量大) 可以透過replica快取降低memory消失的風險 評估 預先知識 QPS - Queries Per Second TPS - Transactions Per Second UV - Unique Visitor RPS - Requests Per Secornd 獲取設計前條件 目前得知的條件 快取大小會是30TB QPS會是10M(每秒一千萬) 估算機器數量 假設我們每台機器都有72G的記憶體，則要存入30TB的資料則需要 30TB / 72G = 420(大約)，而這是剛剛好的數目，有可能需要增加，因為我們每秒要附和10M的搜尋流量。 設計目標 設計目標三巨頭 Latency(延遲) Consistency(一致性) Availability(可使用性) 快取系統的設計目標 快取的用意就在於降低延遲，DB的寫入是依靠硬碟的而快取是依靠記憶體，有基本計算機常識的話就可以知道

清單 前言 預備知識 CAP理論 前言 在做任何系統設計前，一定要自我先釐清整個系統會使用到的儲存空間會多大，可以透過不同的Use Case去思考，可能的使用量，當整個Storage都出來後再開始設計，系統會更加穩固，整個系統設計也會更貼切使用者的需求。 預備知識 關聯式資料庫 正規化 實踐方法 基本NoSQL概念 Concurrency知識 多執行序開發 死結 鎖 Neworking TCP/IP UDP File Systmes OS基礎 File System 如何運作 Database 如何運作 OS如何控制Cache 常用詞彙 Replication 複製品 其實也就是冗於，冗於通常用於災害發生時當作備案 Consistency 一致性 當分佈式系統時，你要怎樣確保使用者用到的檔案/資料是一致的 Eventual consistency 最終一致性 資料可以暫時的不同，但在使用者可以接受的時間內會達到一致 也代表說在當下可以暫時的不一致，但長時間內需正確 例如(座位餘額/即時時刻表) Availability 可使用性 服務是不是可以7*24提供服務 Partition Tolerance 部分容忍 多節點有災難時(通訊失敗/Crash)但是還是可以正常運行 Vertical scaling and Horizontal scaling Vertical scaling 垂直擴增 替機器增加資源(記憶體/硬碟/CPU) Horizontal scaling 增加Server的數量 Sharding 分片管理 將龐大的資訊切分成小部分，讓他可以更有效率 CAP理論 Consistency Availability Partition Tolerance 詳細的CAP範例可以參考我的另一篇翻譯文章 系統設計 - 基礎概念 CAP (Consistency, Availability, Partition Tolerance) 系統設計的五個步驟 釐清需求 估算資料量大小，該如何處理 如何Sharding 如何Caching 找出關鍵瓶頸點 找到此系統使用者最在乎

前言 此篇文章是Design Pattern的導覽頁面 項目 雜談 三本書搞定Design Pattern Creational Patterns 設計模式 - 建構者模式 (Creational Patterns - Build Pattern) 設計模式 - 工廠模式 (Creational Patterns - Factory Pattern) 設計模式 - 單例模式 (Creational Patterns - Singleton Pattern) 設計模式 - 原型模式 (Creational Patterns - Prototype Pattern) Structural Ptterns 設計模式 - 適配器模式 (Structural Patterns- Adapter Pattern) 設計模式 - 橋接模式 (Structural Patterns - Bridge Pattern) 設計模式 - 組合模式 (Structural Patterns - Composite Design Pattern) 設計模式 - 裝飾者模式 (Structural Patterns - Decorator Design Pattern) 設計模式 - 包裝模式 (Structural Patterns - Facade Design Pattern) 設計模式 - 享元模式 (Structural Patterns - Flyweight Design Pattern) 設計模式 - 代理人模式 (Structural Patterns - Proxy Design Pattern) Behavioral Patterns 設計模式 - 策略模式 (Behavioral Patterns - Strategy Design Pattern) 設計模式 - 狀態模式 (Behavioral Patterns - State Design Pattern) 設計模式 - 模板方法模式 (Behavioral Patterns - Template Method Design Pattern) 設計模式 - 責任鍊模式 (Behavioral Patterns - Chain of Responsibil

前言 這篇文章推薦我在自學Design Pattern時閱讀的書籍，以及分享我學習的歷程(當然還在持續增進中)。 先來聊聊自己接觸Design Pattern的心路歷程 在我碩一的時候開始閱讀Design Pattern，完全是霧裡看花，只是記住Pattern的名稱。而開始工作第一年，在讀一次對於一些基本封裝的Pattern開始有點感覺，但實際要用到專案上還是有點距離，到目前工作三年了，自己也開始主導一些專案後，再回來複習一次，發現許多Pattern我早就默默地在使用了，而且對於每個Pattern都有許多的感觸與自己的想法。 總歸這些年來對於Design Pattern的心得，我覺得Design Pattern他並不是一個要去學的東西，它更像是一個經驗的總和與梳理，當自己做過的專案不多時道聽塗說的使用，其實這樣一輩子都不會知道自己為什麼要使用Design Pattern，但是在自己實踐過的專案變多後，看過太多失控的程式碼，看過太多修改的坑坑洞洞，就會知道每個Design Pattern它的核心價值以及未來使用的方向。 廢話不多說，下面馬上介紹我個人在學習Design Pattern時閱讀的書籍。 深入淺出－設計模式 深入淺出不必多說，是每個初學者都需要看的書，不管甚麼系列。深入淺出－設計模式這本書可以讓初學者透過書上的實作慢慢地去理解，去想像Pattern的使用，它是以漸進式的方法讓讀者知道每個Pattern使用時機。 博客來訂購連結 設計模式的解析與活用 設計模式的解析與活用，與深入淺出比較大的差異在於，深入淺出用比較多讓讀者會感興趣的方式教學甚麼是設計模式，所以適合初學者。而這本設計模式的解析與活用它會強調使用的時機，並且深入的解析Pattern的使用時機，還有帶領開發者們從Code的層面變成從Pattern的層面去設計。 博客來訂購連結 揭開設計模式的秘辛：設計模式 第1¾版 揭開設計模式的秘辛：設計模式 第1¾版，是我推薦的最後一本書，也是我認為看完上述兩本後在開始閱讀的書。這本書更多在於思考的昇華，還有介紹兩個不再23個模式中的Design Pattern，在第二章節還有一個較大型的設計範例，讓讀者不會只圍繞一個Design Pattern學習，而是用全部的Design Pattern去思考。 博客來訂購連結 結論 用

前言 對我個人而言，其實我私心認為Command Pattern與Chain of Responsibility是非常相似的。 Chain of Responsibility意旨將邏輯拆開，透過物件之間的連接做呼叫，物件間的聯就透過建構者或Dependency Inject注入。 而其中的差別在於，粒度的不同，Commande Pattern比較偏向將一個物件原本的method拆解成一個個的Command，而Chain of Responsibility的Handler粒度更大一點，更像是一個個完整邏輯的物件。 類別圖 設計Command介面 實作Command介面並解複寫Execute方法 透過Receiver組裝Command組織成自己的物件邏輯，提供給Client呼叫 範例 英雄遊戲中的，常用組合招式非常適合用Command Pattern實踐，邏輯如下 使用者可以將不同招式組裝成快捷鍵施放 範例: 施毒 -> 祝福(加攻擊力) -> 攻擊 實作過程 設計SkillCommand 設計不同的Skill實作SkillComand並複寫Method實踐自己的邏輯 透過一個Reciver組裝每個Skill包裝成自己的邏輯 Client執行 import java.util.LinkedList; import java.util.Queue; interface SkillCommand { void execute(); } class Poison implements SkillCommand { @Override public void execute() { System.out.println("Poison your enemy"); } } class Bless implements SkillCommand { @Override public void execute() { System.out.println("Bless yourself"); } } class Attack implements SkillCommand {

前言 觀察者(Observer Pattern) 定義 創造一對多的連結(Subject-Observer)，當被綁定的物件狀態變動的話，則通知其他物件 可以保護物件不做內部破壞去通知其他物件執行功能，可以透過觀察者封裝此物件執行通知 我們只要設想，觀察者就是一個廣播機制，Subject是負責廣播的而和他同個頻道(Observer)都可以接收到他的廣播，在Observer Pattern使用物件導向(多形、封裝)的方法去實踐他 類別圖 創建Subject介面負責和Observer關聯 Observer主要透過Subject的觸發，接收更動的訊息 範例 英雄遊戲中適合使用Observer Pattern(觀察者模式)，非遊戲地圖莫屬。我們現在的遊戲業務內容是，每一張地圖都需要排隊，玩家可以訂閱此地圖(若是當地圖開放的時候(沒人在裡面)就會通知玩家) 設計MapSubject負責發送通知的內容 將地圖繼承MapSubject擴充發送通知的方法 設計UserObserver負責接收通知內容 將User繼承UserObserver擴充收通知的方法 import java.util.ArrayList; import java.util.List; abstract class MapSubject { private String mapId; public MapSubject(String mapId) { this.mapId = mapId; } private List<MapObserver> observers = new ArrayList<>(); public void addObserver(MapObserver mapObserver) { observers.add(mapObserver); } public void notifyChange() { for (MapObserver mapObserver : observers) { mapObserver.update(mapId); } }; } class