問題簡述：一個應用系統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_T2和Topic_T3中的訊息，定時批次查詢本地客戶資訊表，並推送訊息到前端。
資料儲存層
MySQL：本地客戶資訊表儲存在MySQL中。可以使用分表分庫策略提高查詢效能。對於高併發讀寫需求，可以考慮讀寫分離。
Redis：作為快取層，加速客戶資訊的查詢，減少資料庫壓力。對於T1的實時性要求，可以將常用客戶資訊快取到Redis中。
資料倉儲推送
每天將訊息資料匯出為檔案，透過定時任務推送到資料倉儲。可以使用Spark等大數據處理工具來生成檔案。
訊息可靠性
訊息儲存和重試機制：Kafka保證訊息不丟失。同時可以設計訊息處理的重試機制，對於處理失敗的訊息進行重試，確保所有訊息都能成功處理。
二、具體流程設計
訊息接收和驗籤解密
接收HTTP請求後，呼叫驗籤解密微服務進行處理。
解密後的訊息根據型別推送到對應的Kafka Topic。
T1訊息處理流程
消費
Topic_T1中的訊息。解密並查詢本地客戶資訊表（先查詢Redis快取，未命中再查MySQL）。
呼叫系統C的介面，推送訊息到前端。
處理完畢後，將訊息標記為已處理。
T2和T3訊息處理流程
定時批次消費
Topic_T2和Topic_T3中的訊息。解密並批次查詢本地客戶資訊表。
批次推送訊息到前端。
處理完畢後，將訊息標記為已處理。
資料倉儲推送流程
每天定時從Kafka中消費所有型別的訊息，生成檔案。
將檔案推送到資料倉儲。
三、效能最佳化
負載均衡和叢集化：透過Nginx和後端伺服器叢集處理高併發請求。
快取最佳化：使用Redis快取客戶資訊，減少資料庫查詢壓力。
資料庫分庫分表：對MySQL進行分庫分表，提升查詢效能。
非同步處理：Kafka非同步處理訊息，解耦接收和處理流程，提高系統吞吐量。
批次處理：T2和T3訊息採用批次處理，減少頻繁IO操作，提高處理效率。
四、容錯和監控
容錯機制
Kafka具備訊息重試和持久化能力，確保訊息不丟失。
系統C介面呼叫失敗時，進行重試或持久化儲存，待後續處理。
監控和報警
使用Prometheus和Grafana進行系統監控，監控指標包括請求量、處理時延、錯誤率等。
設定報警策略，當處理時延或錯誤率超出閾值時，及時報警處理。
五、總結一下
透過上述設計，我們可以構建一個高效、可靠的訊息接收和處理系統，滿足每月150億條訊息的處理需求。系統採用Kafka作為訊息佇列，結合MySQL和Redis進行資料儲存和查詢，透過非同步和批次處理機制，確保訊息的實時性和可靠性。
同時，透過負載均衡、快取最佳化和資料庫分庫分表，提升系統的效能和擴充套件性。
最後，透過完善的監控和容錯機制，保障系統的穩定執行。
