切換語言為:簡體

該如何設計設計一個能夠接收和處理每月約150億條訊息的系統?

  • 爱糖宝
  • 2024-07-17
  • 2055
  • 0
  • 0

問題簡述:一個應用系統A 需要透過HTTP介面接收某外部系統B的訊息,系統 A 提供3個介面,接收來自系統B的三類訊息,每月資料總量約150億條,經處理後推送前端。

請問如何設計:

這3個介面每次被呼叫一般就透過請求入參最多送10條資料,大多數情況一次呼叫大概送兩三條資料,總共資料量一個月大概150億條,其中1個介面T1推送過來的訊息實時性要求較高,一般要求15秒內要處理完推送到前端渠道,並且訊息量大概佔了總量的70%,另外兩個介面T2和T3推送過來的訊息實時性要求較低,當天能推送給使用者即可,這兩個介面的訊息總量佔總量的30%。每次介面呼叫包含的資料陣列大小不超過10,陣列裡的資料物件為JSON物件,不超過10個欄位,每個欄位值不超過30個字元。介面是加密的,需要驗籤解密後得到明文。

系統A 接收資料進行處理的需求如下:

(1)拿到介面推送的資料,對於每一條資料進行解密後,查詢本地客戶資訊表(單表,大概3000萬條資料),對於屬於本地客戶的訊息資料,呼叫系統C的介面推送訊息給前端渠道。

(2)對於上面三類訊息的所有資料,每一類訊息都需要推送給資料倉儲,目前推送的方式是每天生成檔案的方式推過去。

(3) 所有訊息不能丟失,介面T1收到的資料要儘量按介面被呼叫的順序來推送,介面T2、T2的順序性要求不高。 請問,大致需要怎麼設計來滿足需求?限於資源情況,主要只能考慮用kafka、redis、mysql。

大規模訊息接收和處理策略設計

在設計一個能夠接收和處理每月約150億條訊息的系統時,我們需要綜合考慮系統的實時性、可靠性和可擴充套件性。以下是針對該問題的一種詳細設計方案。

一、系統架構設計

訊息接收層

HTTP 介面:系統A提供三個HTTP介面(T1, T2, T3)接收來自系統B的訊息。考慮到高併發情況,可以使用Nginx作為反向代理,並透過負載均衡將請求分發到多個後端伺服器。

加密和驗籤:每條訊息需要經過驗籤和解密,可以考慮使用獨立的微服務來處理這部分邏輯,以減少主業務邏輯的負擔。

訊息佇列層

Kafka:使用Kafka作為訊息佇列系統,將接收到的訊息推送到不同的Topic中。T1的訊息推送到Topic_T1,T2的訊息推送到Topic_T2,T3的訊息推送到Topic_T3。Kafka能夠保證訊息的順序性和高吞吐量,非常適合這種大規模訊息處理的場景。

數據處理層

實時處理(T1):對於實時性要求高的T1訊息,可以使用Kafka Streams或Flink來處理。消費Topic_T1中的訊息,解密後查詢本地客戶資訊表(MySQL),並呼叫系統C的介面推送訊息到前端。

批次處理(T2, T3):對於T2和T3訊息,可以採用批次處理的方式。消費Topic_T2Topic_T3中的訊息,定時批次查詢本地客戶資訊表,並推送訊息到前端。

資料儲存層

MySQL:本地客戶資訊表儲存在MySQL中。可以使用分表分庫策略提高查詢效能。對於高併發讀寫需求,可以考慮讀寫分離。

Redis:作為快取層,加速客戶資訊的查詢,減少資料庫壓力。對於T1的實時性要求,可以將常用客戶資訊快取到Redis中。

資料倉儲推送

每天將訊息資料匯出為檔案,透過定時任務推送到資料倉儲。可以使用Spark等大數據處理工具來生成檔案。

訊息可靠性

訊息儲存和重試機制:Kafka保證訊息不丟失。同時可以設計訊息處理的重試機制,對於處理失敗的訊息進行重試,確保所有訊息都能成功處理。

二、具體流程設計

訊息接收和驗籤解密

  • 接收HTTP請求後,呼叫驗籤解密微服務進行處理。

  • 解密後的訊息根據型別推送到對應的Kafka Topic。

T1訊息處理流程

  • 消費Topic_T1中的訊息。

  • 解密並查詢本地客戶資訊表(先查詢Redis快取,未命中再查MySQL)。

  • 呼叫系統C的介面,推送訊息到前端。

  • 處理完畢後,將訊息標記為已處理。

T2和T3訊息處理流程

  • 定時批次消費Topic_T2Topic_T3中的訊息。

  • 解密並批次查詢本地客戶資訊表。

  • 批次推送訊息到前端。

  • 處理完畢後,將訊息標記為已處理。

資料倉儲推送流程

  • 每天定時從Kafka中消費所有型別的訊息,生成檔案。

  • 將檔案推送到資料倉儲。

三、效能最佳化

  1. 負載均衡和叢集化:透過Nginx和後端伺服器叢集處理高併發請求。

  2. 快取最佳化:使用Redis快取客戶資訊,減少資料庫查詢壓力。

  3. 資料庫分庫分表:對MySQL進行分庫分表,提升查詢效能。

  4. 非同步處理:Kafka非同步處理訊息,解耦接收和處理流程,提高系統吞吐量。

  5. 批次處理:T2和T3訊息採用批次處理,減少頻繁IO操作,提高處理效率。

四、容錯和監控

容錯機制

  • Kafka具備訊息重試和持久化能力,確保訊息不丟失。

  • 系統C介面呼叫失敗時,進行重試或持久化儲存,待後續處理。

監控和報警

  • 使用Prometheus和Grafana進行系統監控,監控指標包括請求量、處理時延、錯誤率等。

  • 設定報警策略,當處理時延或錯誤率超出閾值時,及時報警處理。

五、總結一下

透過上述設計,我們可以構建一個高效、可靠的訊息接收和處理系統,滿足每月150億條訊息的處理需求。系統採用Kafka作為訊息佇列,結合MySQL和Redis進行資料儲存和查詢,透過非同步和批次處理機制,確保訊息的實時性和可靠性。

同時,透過負載均衡、快取最佳化和資料庫分庫分表,提升系統的效能和擴充套件性。

最後,透過完善的監控和容錯機制,保障系統的穩定執行。

0則評論

您的電子郵件等資訊不會被公開,以下所有項目均必填

OK! You can skip this field.