iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 19
1
AI & Data

資料工程師修煉之路系列 第 19

[Day 19] Encoding and Evolution (5-2) - Mode of Dataflow - asynchronous message-passing 和總結

接續 Day 18

通過非同步訊息傳遞的 Data Flow

最後要來介紹 asynchronous message-passing (非同步訊息傳遞) 系統,它的特性介於 RPC 和資料庫之間,client 的 request (通常稱為 message ) 會低延遲的傳遞給另一個 process ,然後會透過一個 message broker (訊息代理) 的角色來暫時儲存 message,message broker 也被稱為 message queuemessage-oriented middleware

使用 message broker 跟 RPC 比起來有幾個好處:

  • 它能在接受者 (recipient) 掛掉或重啟時當 buffer,所以能提高系統的可靠性 (reliability)。
  • 它能自動重送 message 給接受者,所以能避免 message 遺失。
  • 它能避免讓寄送者 (sender) 知道接受者的 IP 或 PORT。
  • 它能允許 message 能被傳給多個接受者。
  • 它能讓寄送者和接受者做到邏輯上的 decouples (解耦合),意為寄送者不會在意是誰接受了它的 message。

asynchronous message-passing (非同步訊息傳遞) 系統跟 RPC 有個最大的不同是 寄送者通常不會期望接收 message 的回應,如果要接收回應的話會用分開的頻道來處理,這種溝通模式稱為 asynchronous:寄送者不會等待 message 被交付,且會送了就忘 (send it and then forgets about it)。

Message broker (訊息代理)

基於此概念下的 open source 工具有 RabbitMQ、ActiveMQ、HornetMQ、NATS 和最多人使用的 Apache Kafka

message broker 的主要用法是:一個 process 寄送 message 給 queue 或 topic,然後 broker (代理) 會確保這個 message 能被交付於另一個 consumers (消費者) 或 subscribers (訂閱者),我們能有許多 producer (生產者) 和 consumers ;

一個 topic 是一個單向的資料流,consumer 也能當 producer 發佈一個 message 給 topic,所以你能把它們連起來或者當處理完 message 的回覆 (就能做到類似 RPC 的 request/response);

message broker 通常不會指定如何做資料的 encoding,一個 message 就是用連續的位元組傳遞,所以你能自由選擇用哪種 binary encoding 格式,相對的就有很大的彈性做到向前和向後兼容。

Distributed actor frameworks (分散式角色框架)

actor 模型是一種為了在同一個 process 做並發 (concurrency) 的程式模型,而不是直接用 執行緒 來做,執行緒的相關問題有:競爭條件 (race condition)、鎖定 (locking) 跟死鎖 (deadlock)。

actor 的特性有:

  • 每一個 actor 代表一個 client 或 entity,它能有 local 的狀態 (不與其他 actor 分享),與其他 actor 的溝通也是透過寄送或接受非同步 message。
  • message 不保證交付,在某些情況下 message 會遺失。
  • 每一個 actor 一次只處理一個 message,所以不用特別擔心執行緒的問題。
  • 每個 actor 都能設定排程做事情。

在 Distributed actor frameworks (分散式角色框架) 中通常會在多個節點執行,所以寄送者和接受者是否在同一個節點不重要,最終都會 encoding 成連續的位元組用網路來傳遞 message;它實質上整合了 Message broker 和 actor 程式模型在單一個框架上,所以當你在 rolling 部署你的 actor-base 應用程式時,得多留意向前和向後兼容的問題。

常用的框架為 Akka、Orleans 和 Erlang OTP。

總結

Encoding and Evolution 主要就是介紹如何把記憶體的資料結構轉成透過網路傳遞或存在硬碟裡的位元組和兼容性;

Rolling upgrades (滾動式升級) 允許你的程式在釋出時不會有 downtime (頻繁的小更新好過一次大更新),也能降低部署時的風險 (能做 canary 觀察新程式上線時情況),因此系統的兼容性就代表了系統的進化能力。

兼容性分 2 種:

  • Backward compatibility (向前兼容)

    新程式要能讀舊程式寫入的資料。

  • Forward compatibility (向後兼容)

    舊程式要能讀新程式寫入的資料。

我們也討論了 binary encoding 的格式:

  • Programming language–specific encoding
  • 文字格式如 JSON, XML, and CSV
  • Binary schema–driven 格式如 Thrift, Protocol Buffers, and Avro

最後則討論了 3 種 dataflow 方式:

  • 資料庫
  • RPC and REST APIs
  • Asynchronous message passing (非同步訊息傳遞)

明天開始要進入全新的章節啦~


上一篇
[Day 18] Encoding and Evolution (5-1) - Mode of Dataflow - DB, REST API, RPC
下一篇
[Day 20] Distributed Data
系列文
資料工程師修煉之路30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言