(InterviewBit) System Design - Storage Scalability

-

清單

  • 前言
  • 預備知識
  • 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
  • 找出關鍵瓶頸點
    • 找到此系統使用者最在乎的地方
    • 分析瓶頸點造成的影響
    • 範例
      • facebook最常使用的功能可能就是讚
      • 如何處理這樣大量的讚回饋
  • 粗略設計框架
  • 仔細分析框架細節

額外資源

Master & Slave

Database讀寫分離

  • Master提供資料的寫入
  • Slave提供資料的讀取
  • Master的資料會以幾乎即時的時間寫入到Slave中

為何要讀寫分離?

  • 當使用流量上升時寫和讀都會消耗CPU的運算速度，而大部分系統讀取的需求都會大於寫入，這時如果將資料庫分為讀取的資料庫和寫入的資料庫，那寫入再也不需要和讀取爭取資源。
  • 方便擴增 - 若是流量像是沒有天際的上升，那切分為讀取的資料庫就可以很簡單的擴增，只要將Master(寫入資料庫一起同步到新的擴增Slave(讀取資料庫))就好

為何讀寫分離會讓搜尋資料更快?

  • 因為將讀操作和寫操作分離，CPU可以將資源全力作其中一項事情

  • 記憶體

    • 讀資料庫可以不須在將讀操作時需要的index載入到記憶體中，進而讓讀操作可以全盤使用記憶體

  • 硬碟

    • 資料庫寫入硬碟時，必須將硬碟的head重新拉到可寫的目標中，在找尋可寫入的目標地址時需要耗號head移動的時間(物理移動)
    • 而寫入則只需要移到資料位子並且讀取就好
    • 若是資料庫讀寫分離的話，讀資料庫(Slave)則可以避免要寫入時，硬碟的磁頭移動需要消耗的時間，(因為磁頭不須再高頻的處理寫入時head的移動，只有在批量同步時才需要)。

  • 去除龐大

    • 資料庫讀寫分離後，你的資料庫不需要像以前依樣那麼龐大，讀寫分離可以帶出新的技術與概念(分庫分表)，常使用的資料可以使用高等一點的Sever。而當機和Crash時，在也不需要等待龐大的資料庫重啟，甚至可以因為分庫分表，想出系統的分布可容錯措施。

留言

張貼留言

這個網誌中的熱門文章

Java Lambda Map篇

-
目的 主要介紹Map中的新方法，包含如下 forEach() getOrDefault() putIfAbsent() remove() replace() replaceAll() merge() 有些是Lambda有些則是我覺得比以前使用Map更方便而介紹 forEach Map的forEach方法與List不大依樣，因為Map主要的迭代方法是以Entry為主，所以需要Key-Value Pair去迭代 原始碼解說 可以看到forEach的傳入參數BiConsumer介面，必須傳入Key與Val，裡面的實作就如同我們使用Java8版本以前的寫法，需要使用for迴圈去迭代抓出每個Value 原始碼 default void forEach(BiConsumer<? super K, ? super V> action) { Objects.requireNonNull(action); for (Map.Entry<K, V> entry : entrySet()) { K k; V v; try { k = entry.getKey(); v = entry.getValue(); } catch(IllegalStateException ise) { // this usually means the entry is no longer in the map. throw new ConcurrentModificationException(ise); } action.accept(k, v); } } 範例 private void forEachExample() { Map<Integer, String> map = new HashMap<>(); map.put(1, "test1"); map.put(2, "test2"); m...
閱讀完整內容

設計模式 - 工廠模式 (Creational Patterns - Factory Pattern)

-
圖片
前言 這篇文章會介紹三個最常使用的工廠模式方法，分別是 Simple Factory (簡單工廠) Abstract Factory (抽象工廠) Factory Method (工廠方法) 其中最容易讓人搞混的是，Abstract Factory和Factory Method，不過對我來說何必太過糾結於這兩個的概念，工廠模式最主要的核心原理就是將你創造物件的邏輯隱藏起來，不向客戶端顯示，我覺得只要知道這個概念就夠了，接下來會介紹這三個種類的工廠模式。 Factory Pattern 工廠模式 Simple Factory 簡單工廠 簡單工廠是工廠模式的第一步，也是工廠模式最基本的核心概念實踐，主要解決的問題是 將創建物件邏輯抽離 解偶Class的複雜度 Class Diagram 將封裝物件邏輯抽出寫成Simple Factory 產出父類別物件的物件 範例 在這個範例我們希望將戰士與魔法師遊戲創造英雄的邏輯抽出並且寫成靜態工廠，戰士與魔法師都是英雄並且’目前’只能進行攻擊，程式碼如下 Interface Hero public interface Hero { void attack(); } Magician.class public class Magician implements Hero { @Override public void attack() { System.out.println("Use magic to attack"); } } Warrior.class public class Warrior implements Hero { @Override public void attack() { System.out.println("Use sword to attack"); } } HeroFactory.class public class HeroFactory { public Hero makeHero(HeroType heroType) { if (heroType.equals(HeroType.MA...
閱讀完整內容

(InterviewBit) System Design - Design Cache System

-
圖片
前言 這是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的寫入是依靠硬碟的而快取是依靠記憶體，有基本計算機常識的話就可以知道...
閱讀完整內容