EXCEL導入—設計與思考

一、案例信息與設計

1.1、案例需求與背景

B2BTC同城二期有一個Excel導入的功能，單次數據量小于一千，使用頻次不高。但涉及到多個字段組成唯一約束，即每條數據操作時要根據唯一性組合字段來操作，要確保數據表中的數據不違反唯一性。

每條數據涉及到多次查詢其他業務RPC來校驗、補充信息的訴求，即使有緩存，但也可能涉及到緩存不命中問題，即單條數據的校驗和導入的時效性保障不了。

?

1.2、整體解決方案

以下四個方案為開發過程中依次思考的四個方案，沒有絕對利弊。

1.2.1、初始構思開發方案（同步導入）

首先想到的方案為常用的同步導入，即在一臺容器的一個線程中完成Excel中數據的解析、校驗、導入、發送通知消息三部分流程。

問題：

1.當數據量過大時，在單臺服務器上操作時對服務器造成比較大的內存壓力。

2.流程比較長，每條數據涉及多次RPC查詢，總體時間很長。接口TP99會比較高 + 用戶體驗很差。

優點：

1.可以讓前端同步獲取導入結果。

?

??

1.2.2、方案二（改進版）

由于方案一時效不可控制，在參考了另外一個Excel導入場景后設計了以下方案：

基于原有的方案，該方案使用了線程池來校驗數據并通過MQ來異步地處理每條數據，這樣基于原有的方案有一定的效率提升。

但由于當時思考不充分，開發完成之后發現和實際場景不適配，并可能有TP99超時風險，只作為記錄。

?

問題：

1.業務可以結束完全的異步，所有的導入結果都通過。

優點：

1.可以讓前端同步獲取校驗結果。

2.線程池和異步處理一定程度上提升了數據處理效率。

適用場景：

本方案適用于前端需要同步獲取導入的結果，后端不涉及唯一性校驗（有單號等唯一主鍵信息）的場景，可以校驗數據之后進行批量插入（不用MQ來發消息異步處理數據）。

?

方案本身沒有什么問題，問題在于方案和引用場景不是最佳適配：本次導入不要求前端能即時獲取到導入的結果，因此無需在這里同步獲取到結果之后再異步處理數據，可以將 excel解析 + 數據校驗 + 處理消息統一均異步處理。

??

?

1.2.3、方案三（最終版）

由于業務方沒有同步獲取導入結果或者校驗結果的任何訴求，因此這里將 excel解析 + 數據校驗 + 處理消息統一均異步處理（JMQ發消息給消費者來處理這些流程），只對必要的參數進行校驗。

對于數據處理，將Excel數據拆分為每條的粒度，用 線程池來進行 數據校驗并處理，最終由主線程統計結果。

此外，在進行數據 查詢唯一性數據 + 操作數據（增加刪除修改） 的最小并發影響粒度加上Redis鎖來保障數據表的唯一性不會被破壞。

?

問題：

1.所有的 excel解析 + 數據校驗 + 處理消息 均在一臺服務器上執行，對服務器的壓力會比較大。

優點：

1.用線程池處理消息，大大縮短了消息處理的時間，減少了單個服務器壓力。

2.有兜底策略，可確保數據不丟失，導入流程可以正常且按時結束，不會無上限等待。

3.除必要校驗的所有流程均異步處理，接口的TP99可靠且較快。

適用場景：

1.對數據完整性要求比較的業務。

2.數據量不會太大的業務。（避免對單個容器造成較大壓力）

??

?

1.2.4、方案四（理想版）

對于方案三，將所有的數據校驗 + 處理的流程都給一臺服務器執行，造成單臺服務器壓力比較大，且并發度不夠高，總體流程時效性可能得不到保障。因此設想了一個較為理想的方案四場景，適用于數據量大、對數據可靠性要求不高、時效性要求高的場景。

相比方案三，方案四減少了對應的對賬、兜底機制，整體的流程還是異步進行。相比于線程池，用 JMQ 發送消息給 數據校驗并處理的consumer來處理消息并記錄結果到Redis來跟蹤導入進度。此外，在進行數據 查詢唯一性數據 + 操作數據（增加刪除修改）+ 更新Redis中最終結果 的最小并發影響粒度加上Redis鎖來保障數據表的唯一性不會被破壞。

?

問題：

1.沒有兜底策略，數據校驗處理的流程中可能出現有一條消息阻塞丟失意外結束，導致最終沒有線程統計結果并發送咚咚消息。

優點：

1.除必要校驗的所有流程均異步處理，接口的TP99可靠且較快。

2.利用拆分導入數據 + 多個Consumer處理消息，大大縮短了消息處理的時間。

3.拆分數據為消息異步處理，用了JMQ的重試機制來提升了數據處理的可靠性。

適用場景：

1.本方案適用于前端無需同步獲取導入的結果，后端可以完全異步處理數據的場景。

2.對數據可靠性要求不是極高的業務，可接受小概率容錯。

3.對導入結果失效有一定訴求的業務。

4.數據量比較大或操作比較頻繁的業務。

?

??

?

二、持續思考

2.1 中間件的合理使用

合理利用JMQ來解耦、拆分業務邏輯可以 減少單臺服務器實例內存或CPU的壓力、提高數據處理并發量，同時可以利用MQ的重試機制來盡可能保障對應業務的可用性。

同時，異步處理可能存在結果丟失的情況，在數據可靠性要求不高的場景可以合理舍棄這種小概率場景發生的問題（因為有重試還一直失敗）。但在數據可靠性要求比較高的場景，需要有對應的對賬機制 + 兜底機制來統計數據的處理情況。（如Excel導入，可以將解析完成的數據 和 最終導入的數據進行一個數據對賬，如果有數據丟失或者無響應，發出告警，讓定時任務 或 人工進行二次核驗來確保數據可靠不丟失）

但中間件的過度使用使得服務過度依賴中間件的可靠性，問題追蹤定位難度會進一步加大，需要結合實際業務場景綜合權衡。

2.2 業務充分適配場景

在進行方案的技術設計時，不要只是照葫蘆畫瓢，要結合自己的業務場景、業務數據量、可靠性要求等場景充分考慮，借鑒其他方案的可用之處。

如本文檔中方案二借鑒了之前的方案設計，但沒有考慮自己的業務場景是不是與其適配，沒有充分適配自己的實際業務，還可能引入新的問題。

沒有最好的技術方案，只有適配于當前業務場景的最佳方案。

審核編輯 黃宇