查理工程記

前言 這是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 找出關鍵瓶頸點 找到此系統使用者最在乎...