最近做了乙個（奇坑的）需求，使用者退款資訊匯出至excel
。聽起來似乎是乙個簡單的小功能，但是做起來卻發現有數不清的大坑- -
，整個專案我大約花了2-3
周時間去開發（當然中間穿插著一些其他的需求），並後續仍在優化或解決bug
。不過現在已經完成，大部份的坑也已經被填滿了。
首先來說下整體的開發流程圖：
對於這個需求，首先我們需要明確一點：必須要非同步來做，匯出任務很耗時間（當記錄較多時，時間會比較長），如果採用同步策略，勢必影響使用者的體驗。
然後我們來分析下開發的流程圖，首先我們有兩個非同步的定時任務：正常的退款匯出任務以及失敗重試的定時任務。前者負責「正常
」任務的執行，後者負責「失敗
」的任務的重試。那麼怎麼來定義任務？我們用了一張表：
task
表。建表語句如下：
主要用到的表字段有以下幾個：taskid, status, rule。taskid
很好理解，每個任務都有自己的編號，我們需要根據編號來執行相依的任務。那麼具體的執行呢？以退款匯出為例，我們需要呼叫退款列表介面，需要的入參如下圖展示的那樣：
可以看到有以下幾個核心的引數：查詢條件、查詢的時間段（起始及終止時間）等。這些底層查詢介面需要的查詢引數就通過json
序列化後寫入
rule
欄位中。
至於status
狀態字段，上面說了我們有兩個非同步任務。我們就根據
status
欄位來判斷任務的執行狀態：
/**
* 訂單狀態
* 未完成 0， 已完成 1， 錯誤 2， 執行中 3
*/init_export_order_task_status(0, "init"),
completed_export_order_task_status(1, "completed"),
error_export_order_task_status(2, "error"),
running_export_order_task_status(3, "running");
首先，當使用者根據查詢條件觸發退款匯出的介面時，前端會將查詢引數傳入後端，後端會在檢查引數有效性、驗證使用者操作許可權後，將入參json
序列化後，向task
表中插入此條記錄。此時該任務的
status為0
。同時，普通的定時任務會從task
表中獲取待執行（
status
為0）的所有任務，隨後多執行緒非同步處理這些任務。執行的步驟是獲取任務中的
rule
字段，然後反序列化後得到入參後，隨後呼叫退款資訊介面，使用者資訊介面及訂單資訊介面。查詢到所有的資訊後將資訊組裝成excel
（這裡使用到了
excel
excel
後並不是直接穿給使用者，而是將
excel
這裡曾經有乙個巨坑，
莫名出現退款匯出任務經常失敗的情況。
debug
後發現，是呼叫使用者服務時出現異常，出現異常時導致整個退款匯出任務返回失敗。再與相關開發人員對齊後發現，我們
呼叫的是老介面，而老介面已經被廢棄，後來使用了使用者服務提供的新介面進行重構
，暫時恢復正常；但是當查詢量過大時又出現任務出錯的情況，後來發現是使用者介面最多支援500
資料的批量查詢。
所以在這裡需要分批處理任務。正常的迴圈呼叫介面會比較費時，後來我們使用了fork-join
框架處理批量介面的呼叫（關於此框架，在下次我會總結下）。
從這個問題中我也是感觸頗多，想給出大家我的血的教訓：1.
呼叫其他團隊同學的介面一定要做好資訊同步，別再出現老介面廢棄了沒人維護了，其他開發方還在使用的情況。2.
在**功能實現上，不能因為某乙個環節出錯（使用者資訊查詢失敗）而導致整個功能出現問題（退款匯出任務失敗，導致使用者沒辦法成功匯出），因為使用者資訊並不是乙個極其重要的資訊，如果沒查詢到，大不了為空即可！優化功能的前提是主業務不能被影響。
為了避免因為某些神奇的異常情況導致正常的退款任務執行失敗。特地加了乙個失敗重試的定時任務，專門執行
status=3
（執行中）的任務。可以看到上面的框圖中有乙個retrynum
的計數器，限制了任務的重試次數。剛開始時是沒有考慮這一點的，那麼這樣出現了一種什麼情況呢？當拿到乙個
「必然執行失敗
」（比如由於邏輯判斷，這個任務永遠不會被成功執行）的任務後，此定時任務會一直執行此任務，又因為這個任務必然會執行失敗，導致定時任務會阻塞。這就很尷尬了！這個任務執行不了，你還犟得和頭牛一樣一定要執行，這不浪費資源浪費時間麼！所以我們設定了任務失敗最多執行的次數，失敗達到上限任務會被標定為真正的「失敗
」，即status=2
。並且這種設計方式還有乙個很尬的問題
——因為當正常定時任務在正式執行任務前，會將任務的狀態更新為
3，而失敗重試的任務將會執行狀態為3
的任務。這就會出現一種情況
——任務也許會被執行多次，然而執行此類任務是一種冪等性的操作，執行多次並不影響結果；但是
——總歸不是一種優雅的設計方案了對吧？暫時也想不出更合理的執行方式～如果有大佬有思路，可以推薦喲～
這次的部落格就到這裡。
我希望世界盃決賽可以看到法國打英格蘭，耶
✌️
微信退款開發 Java
原文 二 編寫 處理退款請求 初始化退款介面需要的資料，隱藏了get和set方法。public class refundreqdatamobimessage實現json資料型別和xml資料之間的轉換。public class mobimessage inputstream.close return ...
微信退款開發過程
商戶號 mch id 隨機字串 nonce str 商戶訂單號 out trade no 商戶退單號 out refund no 退款總金額 refund fee 訂單總金額 total fee 操作員帳號 op user id 商戶平台中對應的key值 key 注意事項 1.訂單總金額和退款總金額...
微信退款開發過程
php view plain copy print?商戶號 mch id 隨機字串 nonce str 商戶訂單號 out trade no 商戶退單號 out refund no 退款總金額 refund fee 訂單總金額 total fee 操作員帳號 op user id 商戶平台中對應的k...