EXCEL導(dǎo)入—設(shè)計與思考

一、案例信息與設(shè)計

1.1、案例需求與背景

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

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

?

1.2、整體解決方案

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

1.2.1、初始構(gòu)思開發(fā)方案（同步導(dǎo)入）

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

問題：

1.當(dāng)數(shù)據(jù)量過大時，在單臺服務(wù)器上操作時對服務(wù)器造成比較大的內(nèi)存壓力。

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

優(yōu)點：

1.可以讓前端同步獲取導(dǎo)入結(jié)果。

?

??

1.2.2、方案二（改進版）

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

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

但由于當(dāng)時思考不充分，開發(fā)完成之后發(fā)現(xiàn)和實際場景不適配，并可能有TP99超時風(fēng)險，只作為記錄。

?

問題：

1.業(yè)務(wù)可以結(jié)束完全的異步，所有的導(dǎo)入結(jié)果都通過。

優(yōu)點：

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

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

適用場景：

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

?

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

??

?

1.2.3、方案三（最終版）

由于業(yè)務(wù)方?jīng)]有同步獲取導(dǎo)入結(jié)果或者校驗結(jié)果的任何訴求，因此這里將 excel解析 + 數(shù)據(jù)校驗 + 處理消息統(tǒng)一均異步處理（JMQ發(fā)消息給消費者來處理這些流程），只對必要的參數(shù)進行校驗。

對于數(shù)據(jù)處理，將Excel數(shù)據(jù)拆分為每條的粒度，用 線程池來進行 數(shù)據(jù)校驗并處理，最終由主線程統(tǒng)計結(jié)果。

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

?

問題：

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

優(yōu)點：

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

2.有兜底策略，可確保數(shù)據(jù)不丟失，導(dǎo)入流程可以正常且按時結(jié)束，不會無上限等待。

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

適用場景：

1.對數(shù)據(jù)完整性要求比較的業(yè)務(wù)。

2.數(shù)據(jù)量不會太大的業(yè)務(wù)。（避免對單個容器造成較大壓力）

??

?

1.2.4、方案四（理想版）

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

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

?

問題：

1.沒有兜底策略，數(shù)據(jù)校驗處理的流程中可能出現(xiàn)有一條消息阻塞丟失意外結(jié)束，導(dǎo)致最終沒有線程統(tǒng)計結(jié)果并發(fā)送咚咚消息。

優(yōu)點：

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

2.利用拆分導(dǎo)入數(shù)據(jù) + 多個Consumer處理消息，大大縮短了消息處理的時間。

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

適用場景：

1.本方案適用于前端無需同步獲取導(dǎo)入的結(jié)果，后端可以完全異步處理數(shù)據(jù)的場景。

2.對數(shù)據(jù)可靠性要求不是極高的業(yè)務(wù)，可接受小概率容錯。

3.對導(dǎo)入結(jié)果失效有一定訴求的業(yè)務(wù)。

4.數(shù)據(jù)量比較大或操作比較頻繁的業(yè)務(wù)。

?

??

?

二、持續(xù)思考

2.1 中間件的合理使用

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

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

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

2.2 業(yè)務(wù)充分適配場景

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

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

沒有最好的技術(shù)方案，只有適配于當(dāng)前業(yè)務(wù)場景的最佳方案。

審核編輯 黃宇