多線程解析文件併發送kafka的應用程序發生故障的原因和解決方案：
1．故障發生的背景：
中國本地服務器上部署了XXXMQ（一種Java編寫的可實時傳輸文件的MQ）服務，國外服務器會實時的通過MQ發送需要解析的文件到本地。
本地服務器上部署了兩個應用程序（應用程序1 ：對外提供的 Webservice ，應用程序2：解析程序 ImportData）。本次出故障的是解析程序ImportData（以下簡稱解析程序）。
2． 解析程序的實現原理：
程序啓動時開啓多線程和定時任務。當服務器的work目錄有文件時先通過定時任務轉移到queue目錄，與此同時將文件放到阻塞隊列中；
多線程從阻塞隊列中獲取文件，解析到數據庫之後，將解析成功的文件移到backup目錄，失敗的移到error目錄；
解析成功的Data Object會根據不同業務規則分別發送到KafKa 服務器對應不同的Topic上（一個線程中進行）； --- 故障點
前置機上部署不同的Kafka Consumer 去消費不同Topic 上的Data Object，插入前置機的數據庫，前置機再部署webservice 對外提供服務。
3．上述標黃的故障點發生的原因：
由於解析到總部數據庫和發送Kafka 的操作在同一個線程中進行，當kafka客戶端在連接服務端的時候，
有可能會拋出TimeoutException （Kafka 的某臺機器宕機或者某個broker節點down 掉），默認會阻塞當前線程1分鐘。以此造成文件的積壓越來越大。
我模擬製造了kafka 內部的一個TimeoutException，work中放了6個文件，啓動2個線程，文件解析總時長需要3分鐘。
第一個文件開始時間：
第一個文件超時時間：
最後一個文件完成時間：
4．解決方案：
a. 總部數據解析入庫後，單獨起一個獨立的線程去向KafKa 發送數據 ，由於KafKa 內部是線程安全的，相比多線程，可能單線程的處理效率更高，佔用系統資源更少。（具體源碼分析可參照參考資料1）
如果發現要發送的數據積壓或者kafka服務器連接異常，將所有未發送完成的數據，實時寫入到一張臨時表中。待KafKa 連接恢復正常後，從臨時表取出數據繼續發送，發完之後立即刪除即可。
如果出現業務高峯期kafka 宕機或者kafka超時連接1個小時以上的情況，直接將臨時表的job停掉即可。發郵件通知所有服務中心全部切換到總部webserice。
b. 多線程將數據解析完之後，會將文件保存在backup 中，單獨起一個job從backup中拿文件，解析後根據不同服務中心發送到Kafka服務端。這樣需要考慮對backup的檢索效率。
c. 多線程在解析文件之前，將work目錄文件先拷貝一份到work1中。work1中的文件單獨做kafka的發送。
這樣相當於同一個文件解析兩次，對系統資源消耗較大；如果出現kafka 宕機，也會造成work1的文件積壓，積壓之後再去解析，若超過1個小時，前置機就無法正常提供服務了。
d. 多線程直接解析入庫，再從數據庫查詢需要發送的數據給kafka服務端。（同一時間段內會持續的對數據庫同一張表造成讀寫，高峯期無法預知數據庫壓力。而且現在的表需要加字段，標記哪些數據未發送完成，
對於未發送成功的，如若kafka 宕機，重複查詢的量加大，加上各服務中心切換過來的壓力（最壞情況），對目前的數據庫是一個很大的考驗）。
綜上，請各位大佬決定採用哪種方案比較合理。本人菜鳥一個，不過還是傾向於方案a。
參考資料：https://www.cnblogs.com/dafanjoy/p/10292875.html （這個作者真的大牛，膜拜~~）
https://blog.csdn.net/lipeng_bigdata/article/details/51112870
