產品需求
產品經理需要匯出一個頁面的所有的資訊到 EXCEL 檔案。
需求分析
對於 excel 匯出，是一個很常見的需求。
最常見的解決方案就是使用 poi 直接同步匯出一個 excel 檔案。
客戶體驗 & 服務效能
- 客戶體驗
如果匯出的檔案比較大，比如幾十萬條資料，同步匯出頁面就會卡主，使用者無法進行其他操作。
- 服務效能
匯出的時候，任務比較耗時就會阻塞主執行緒。
如果匯出的服務是暴露給外部（前後端分離），這種大量的資料傳輸十分消耗效能。
解決方案
使用異常處理匯出請求，後臺 MQ 通知自己進行處理。
MQ 消費之後，多執行緒處理 excel 檔案匯出，生成檔案後上傳到 FTP 等檔案伺服器。
前端直接查詢並且展現對應的任務執行列表，去 FTP 等檔案伺服器下載檔案即可。
EXCEL 匯出需要考慮的問題
OOM
正常的 poi 在處理比較大的 excel 的時候，會出現記憶體溢位。
網上的解決方案也比較多。
比如官方的 SXSSF (Since POI 3.8 beta3) 解決方式。
當然，這種寫法比較麻煩。
可以選擇一些封裝好的 excel 工具，解決 oom 問題：
iexcel excel 更加優雅地讀取和寫入，解決 excel OOM 問題
FULL GC
如果一次查詢 100W 條資料庫，然後把這些資訊全部載入到記憶體中，是不可取的。
建議有2個：
-
限制每一次分頁的數量。比如一次最多查詢 1w 條。分成 100 次查詢。(必須)
-
限制查詢得總條數。比如限制為最多 10W 條。（根據實際情況選擇）
雖然使用者提出要匯出類似於 3 個月的所有資訊，但是數量太多，毫無意義。(提出者自己可能體會不到)
儘量避免 FULL-GC 的情況發生，因為目前的所有方式對於 excel 的輸出流都會佔用記憶體，100W 條很容易導致 FULL-GC。
資料庫的壓力
去資料庫讀取的時候一定要記得分頁，免得給資料庫太大的壓力。
一次讀取太多，也會導致記憶體直線上升。
比如 100W 條資料，則分成 100 次去資料庫讀取。
網路傳輸
傳統的 excel 匯出，都是前端一個請求，直接 HTTP 同步返回。匯出 100W 條，就在那裡傻等。
這客戶體驗不友好，而且網路傳輸，系統佔用多種問題。
建議使用非同步處理的方式，將檔案上傳到檔案伺服器。前端直接去檔案伺服器讀取。
程式設計的便利性
對於上面提到的工具，比如 Hutool，在表頭的處理方面沒法很方便的統一。
你可以自己定義類似於 easypoi/easyexcel 中的註解，自己反射解析。
然後統一處理表頭即可。