【Excel_To_DB】SpringBoot+EasyPoi+Redis消息隊列實現Excel批量異步導入數據庫（一）
【Excel_To_DB】SpringBoot+EasyPoi+Redis消息隊列實現Excel批量異步導入數據庫（二）
【Excel_To_DB】SpringBoot+EasyPoi+Redis消息隊列實現Excel批量異步導入數據庫（三）
【效果演示】：JavaWeb畢業設計項目-足球隊管理系統（四）引入Excel_To_DB項目+源碼
【碼雲地址】：https://gitee.com/ydc_coding
前言：
這是一款將Excel表格中的數據導入至數據庫中的小工具，爲什麼會突然想做這個呢？
這是源於兩次抱怨，第一次抱怨是發生在公司開發的人事系統正式在審計局上線前的培訓會上，甲方使用人員提出:爲什麼沒有批量導入數據的功能，在這之前，他們已經在使用另外一款其他公司開發的功能類似的系統，需要將那邊系統的數據同步至這個新的系統上，如果只能依次手動輸入的話，他們工作量反而增大了….
第二次是來自審計局服務辦運維同事的抱怨：新上線人事系統中的個人基礎數據需要進行更正校驗，將之前試運行階段中添加進去的數據與人事處最新發布的個人信息相匹配，將有變化的數據進行更正或刪除新增…這已經是第二次校驗了，上一次足足花了2天的時間才完整的手動校驗完成…
分析：
依照上訴同事的需求(甲方的需求呢？嗯？甲方的需求？甲方剛剛又提什麼需求了？？？)，個人感覺可以往以下幾個方面去考慮：
- 因爲需要同步的數據是變化的，全國這麼多服務辦，每個地區數據庫裏的字段又不太相同，所以不能實體類的字段名稱“寫死”，並且在對應mapper中用註解的形式綁定sql語句，方便後期運維同事自行維護。
- 從過程上來分析，我們需要對傳入的數據進行至少兩層操作，例如首先對傳入的數據進行格式校驗，再將數據插入數據庫後返回的結果進行判斷是否操作成功。
- 從結果上來分析，我們希望能不僅僅只把成功或失敗的“個數”反饋給我們，還希望能把對應的數據以Excel的形式再回傳給我們，方便我們的運維同事在此基礎上進行二次編輯調整。
- 因考慮到需要同步的數據較大，如果使用直接請求訪問的方式，可能請求響應的時間就太長了，所以可以使用消息隊列來進行異步處理，以此來減少請求響應時間和解耦。
技術選擇：
綜合以上考慮：
前端選擇用：Thymeleaf、JQuery、Layui、Layer搭建基礎操作模塊，用echarts構建返回的數據同步結果信息；
後端選擇用：SpringBoot、Mybatis快速搭建項目；
消息中間件選擇用：Redis（緩存、發佈訂閱模式）、Druid（連接池）；
其他依賴Jar包：EasyPoi、FastJson、Lombok….
這裏爲什麼選擇用Redis呢？
- 首先可以作爲緩存，將導入過程中產生的各種數據進行暫時存儲。
- 再者因爲甲方這邊的服務器上已經搭建了另外一款已過保的商用消息中間件-TongLINK/Q(類似於IBM MQ)，不太方便對其進行操作，所以選擇用Redis自帶的發佈訂閱模式以此來實現消息隊列的效果。
業務介紹：
說明：默認首頁，UI模板使用的是layui的後臺佈局-Layui
說明：點擊後，選中需要上傳的Excel文件
說明：上傳後，首先會出現加載層，防止用戶多次重複上傳
說明：返回數據格式校驗後的結果，這是第一層操作，此時後臺已經把通過第一層數據校驗後的數據發佈至消息隊列中，消費者此時正在異步的處理數據。這一塊的請求響應時間是比較短的，因爲這裏我們並沒有直接對數據庫進行操作，只是把數據發佈至對應的頻道中。
說明：這裏是防止用戶在前一步時手誤選擇”不需要”後的一次冗餘的補救措施。
說明：在上一步選擇“需要”後，就可以實時的查看當前消息隊列中未被消費的數據，直至所有的數據都被消費後，彈出詢問框。點擊“立即查看”後，會直接以彈出層的形式，全屏展示數據同步結果；點擊“稍等”，則會在一定時間後再次進行詢問。
說明:
1.左下角的餅狀圖：對第一層操作(數據格式校驗)的結果進行統計；
2.右下角的餅狀圖：對第二層操作(數據導入數據庫)的結果進行統計;
3.中間大的餅狀圖：對總體同步數據庫的結果進行統計；
4.點擊左下角或右下角的餅狀圖，可以下載對應操作未通過的數據；
說明：點擊下載Excel模板
說明：點擊後，打開新窗口跳轉至Druid連接池監控頁面
說明：對上傳Excel文件過程中，可能存在的異常信息進行了封裝反饋給用戶。
總結
總體的業務邏輯與其對應實現的技術都比較簡單，但前前後後也用了接近一週的時間去完成
一是每天能留給自己去寫東西的時間不多，再者確實是因爲長時間使用公司內部封裝的框架，導致對以前玩過的一些框架有一些生疏，開發起來不怎麼順手。當然，正好利用這次機會，去重新複習穩固一下那些遺忘的框架知識點
總的來說，受益匪淺啊~