目錄
- 一、業務背景
- 二、場景分析
- 三、流程設計
- 1、業務流程
- 2、匯入流程
- 3、匯出流程
- 四、結構設計
- 五、實踐總結
- 六、參考原始碼
只想寫單表和檔案的搬運，資料不過百最好；
一、業務背景
最近遇到這樣一個場景：在業務正式開始前1-2天，需要匯入一批來自合作渠道的資料，在業務周期結束后，再將同一批資料匯出，交付給渠道方；
簡單理解，就是資料的「匯入」和「匯出」；
但是場景復雜度的高低與否，與實作流程和邏輯的復雜度并無什么必然聯系，資料在「匯入」和「匯出」之間，通常還會橫著復雜的「業務邏輯」；
資料如果只是在檔案和單表直接來回搗騰，解決的方案簡直花里胡哨，然而在應用中資料匯入匯出，更多還是要集成業務需求，自然也就繞不開業務的處理邏輯；
二、場景分析
1、檔案特征
檔案：「Excel」型別，并且表頭是固定格式，欄位內容雖然有要求，但是難免存在細微的誤差問題；
內容：條數「1000」以內，單條資料「150+」個欄位，業務結束后匯出，會添加業務結果和明細相關欄位，最終在「200」個欄位左右；
2、業務特征
檔案匯入后，資料在業務之間流轉時，需要構建相應的主體結構，比如基礎的「客戶檔案」，「業務檔案」，業務處理程序中會生成「明細」，處理完成后會生成「結果」；
3、資料規則
【客戶檔案】
資料在入庫的程序中，需要校驗「客戶歸屬」問題，庫內已有的客戶基于「跟進時間」執行「更新邏輯」，庫內沒有的客戶需要「新增」并「分配跟進人員」；
【業務檔案】
跟隨「客戶檔案」的邏輯，如果客戶更新，則「業務檔案」更新，如果客戶不更新，則「業務檔案」不更新，如果客戶新增，則「業務檔案」直接新增即可；
【資料校驗】
客戶的「基礎檔案」和「業務檔案」的入庫邏輯，完全遵守產品體系現有的限制規則，在邏輯攔截時盡量輸出全面的攔截原因，方便商務人員對檔案資料進行修改調整；
三、流程設計
1、業務流程
業務流程從整體上可以拆分四段來看：動作確認、動作監聽、資料處理、業務處理；
【動作確認】
- 「匯入」應用前端完成檔案上傳OSS的處理，向應用后端提交資料匯入的請求，接收請求后會異步處理；
- 「例外記錄下載」會實時回應，功能上看就是一個單表匯出，需要回傳業務攔截和例外資訊；
- 「匯出」因為交付時間不確定性，所以由商務人員手動觸發匯出，后端組裝完成后提交OSS檔案服務器，等待下載；
【動作監聽】
- 「匯入」和「匯出」的動作監聽，進而觸發相應的流程邏輯；
【資料處理】
- 「客戶檔案」提交給客戶服務處理，如果處理失敗，無法圍繞客戶構建業務流，直接中斷全部流程；
- 「業務檔案」提交給業務服務處理，這里指業務屬性的資料資訊，并非場景流程；
【業務處理】
- 「資料匯入」的真正目的，依賴系統的處理能力，從而實作相應的業務流程，在程序中會生成關鍵明細和結果資料；
2、匯入流程
- 【1】應用后端接收用戶提交的「匯入」請求，動作接收成功后立即回應；
- 【2】完成「匯入」記錄的存盤之后，通過MQ訊息佇列，解耦檔案資料的處理流程；
- 【3】對檔案進行決議，讀取源資料并存盤到明細表；
- 【4】遍歷明細資料分別實作「客戶」和「業務」的檔案存盤，此處會把失敗原因最大限度回寫到明細記錄中，方便商務二次匯入；
- 【5】完成資料入庫后，更新「匯入」動作的狀態，最核心的是提供失敗記錄的明細和下載功能；
3、匯出流程
- 【1】應用后端接收用戶提交的「匯出」請求，動作接收成功后立即回應，初始狀態為：「處理中」；
- 【2】完成「匯出」記錄的存盤之后，通過MQ訊息佇列，解耦檔案的「創建」和「上傳」流程；
- 【3】檔案資料分為兩部分，檔案原內容和業務處理結果，組裝為新的資料結構；
- 【4】創建新的檔案，涉及資料表頭的合并，資料內容的合并，以及「Excel」的格式構建，從而完成檔案的生成程序；
- 【5】將生成的檔案上傳到檔案服務器，由商務人員自行下載并匯出，然后交付給渠道方；
四、結構設計
資料匯入的表結構，是由具體業務場景決定的，此處就不做展示了；這里只看一看匯入匯出的調度表結構，即操作記錄和狀態以及資料明細的存盤；
【動作記錄】
存盤「匯入」和「匯出」的請求記錄，都涉及檔案資訊的管理，至于「業務ID」和「批次ID」是指集成業務的處理流程，同時也可以基于該「ID」限制同批次下的重復動作，降低不必要的資源占用；
【資料明細】
在「匯入」的時候，對檔案資料的臨時記錄表，方便對資料的多次讀取和處理，避免流程中斷導致檔案的重復決議；
在「匯出」的時候，需要依賴原資料的構建新的「Excel」檔案，在交付渠道方時保證原內容的不變，只新增系統中業務的處理明細和結果；
五、實踐總結
雖然對于「Excel」或者其他檔案的「匯入」和「匯出」的參考案例很多；
但是在研發實踐中，這依舊是一個不容易實作的程序，在資料和檔案互相搬運的程序中，如何與「業務場景」進行平穩的集成，才是真正的復雜邏輯；
從開始作業直到現在，關于「匯入」和「匯出」的實作方案參考或者落地過很多個，整體可以從兩個方向考慮；
【應用系統】
通常檔案格式是「Excel」、「Word」、「Pdf」等，并且涉及的資料體量并不大，采取「異步」的方式解耦即可；
對于檔案的「匯入」來說，需要重點考慮的邏輯，在于如何與業務平穩集成，在出現問題時，能夠給產品頁面準確的資訊反饋，從而提高檔案的二次處理效率；
對于資料的「匯出」來說，是一個「高危」的操作，通常是不分配大量資料的匯出「權限」，如果有需求則要對資料進行計算分「批次」匯出；
【資料系統】
資料體量較大的情況下，不推薦從應用系統考慮「優化」的策略；
如何確定「資料體量較大」的臨界值，需要測驗系統的處理能力，系統業務流量高峰時，去「并發」執行匯入和匯出，從而得出合理的數值，不過大部分產品都是限制單檔案最大「5000」條；
從分布式架構中組裝大量的資料并「匯出」檔案，其資源占用過高，并非主流的實踐方案；
當下比較常見的方式，直接從「資料層面」入手，搭建「傳輸」或「轉換」的通道，以「API」或者「頁面入口」的方式，觸發流程即可；
在資料體量超過應用系統的處理能力時，會搭建專用的「資料傳輸通道」來處理；
這種模式在資料型業務中很常用，可以隔離大量資料的「IO流」操作，確保應用系統運行的安全穩定，也可以極大提升資料和檔案互相搬運的處理效率；
六、參考原始碼
編程檔案：
https://gitee.com/cicadasmile/butte-java-note
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/548282.html
標籤：Java
上一篇：三天吃透MySQL面試八股文