巨型服務架構:Ch5 輸入輸出設計 閱讀筆記

本文為「巨型服務架構」第五章 輸入輸出設計 閱讀重點筆記。有興趣的朋友們歡迎購買原書來閱讀。

巨型服務架構:Ch5 輸入輸出設計 閱讀筆記

定義呼叫方和接收方的訊息通訊機制

  1. 同步:
    1. 呼叫方發出 request,直到接收方處理完成,才能收到 response
    2. 發,收
  2. 非同步:
    1. 呼叫方發出 request,會先收到接收方回傳的 response,但要求尚未處理完成。之後接收方處理完再回傳給呼叫方
    2. 發,收,收

定義呼叫方發出 request 到收到 response 之間的狀態

  1. 阻塞:
    1. 呼叫方發出 request,再等到 response 之前都必須暫停,直到 response 回來才能繼續下去
    2. 發,停下等待,收
  2. 非阻塞:
    1. 呼叫方發出 request,再等到 response 之前可以繼續做別的事情,不會被暫停
    2. 發,做別的事,收

非同步作業,討論阻塞和非組塞沒有太大的意義,因為非同步會立刻得到回應。因此一般我們提

  1. 阻塞式IO == 同步阻塞式IO
  2. 非阻塞式IO == 同步非阻塞式IO

IO模型

  1. 直接操作介面:通常是嵌入式系統
    1. 程式直接對介面進行雙向操作
    2. 程式 <-> 介面
  2. 操作快取:一般我們遇到的系統皆是
    1. 程式會透過快取對介面進行兩階段雙向操作
    2. 發送資料:程式 -> 快取 -> 介面
    3. 接收資料:程式 <- 快取 <- 介面

阻塞式 IO 模型 (Blocking IO, BIO)

  1. 常見的 IO 模型
  2. 呼叫方呼叫 IO 操作後,執行緒被暫停,等待接收階段 (介面 -> 快取) 和 複製階段 (快取 -> 程式) 完成後才會被喚醒

非阻塞式 IO 模型 (Non-blocking IO, NIO)

  1. 呼叫方發起 IO 操作,無論接收階段是否完成,IO 會立刻發出回應
  2. 呼叫方執行緒不會被暫停
  3. 呼叫方必須自行輪詢 IO 狀態來得知是否接收完成
  4. 雖然呼叫方不會被暫停,但輪詢 IO 卻會帶來性能的浪費
  5. 是同步非阻塞操作
  6. 不常用此模型,但會作為後面模型的基礎

訊號驅動式 IO 模型

  1. 因為非組塞要輪詢浪費效能,這邊改用監聽的方式來優化
  2. 先註冊監聽。監聽 callback 後再進行 IO 操作
  3. 是非同步操作
  4. 不常用此模型,但會作為後面模型的基礎

重複使用式 IO 模型

  1. 與訊號驅動式非常相似,但是在註冊監聽後會被阻塞,直到 callback 回來才能操作
  2. 這個模型再度將非阻塞變成阻塞,直覺上不合理
  3. 差異是一次灑出多個 IO 操作,並註冊同一個監聽後阻塞
  4. IO 只要其一接收完成,就會呼叫 callback,程式即可被喚醒並處理資料
  5. 解決阻塞式模型一執行緒只能做一 IO 操作

非同步式 IO 模型

  1. 訊號驅動式設定監聽並回呼後,需要自行再對 IO 操作取得資料,這兩步驟是必然的順序
  2. 此模型直接將兩步驟做掉,不用在程式中顯式做兩次呼叫
  3. 只需設定監聽,最後回呼就能得到資料
Written by J
雖然大學唸的是生物,但持著興趣與熱情自學,畢業後轉戰硬體工程師,與宅宅工程師們一起過著沒日沒夜的生活,做著台灣最薄的 intel 筆電,要與 macbook air 比拼。 離開後,憑著一股傻勁與朋友創業,再度轉戰軟體工程師,一手扛起前後端、雙平台 app 開發,過程中雖跌跌撞撞,卻也累計不少經驗。 可惜不是那 1% 的成功人士,於是加入其他成功人士的新創公司,專職開發後端。沒想到卻在採前人坑的過程中,拓寬了眼界,得到了深層的領悟。