能站别躺，為什麼？因為能減肥呀。一樣的，能異步别同步，畢竟對于性能、響應都是好的。最近在做基于老系統拓展批量導入的功能，與老系統的互動就用DUBBO RPC了，不接MQ了。
如果是走RPC同步業務處理接口，就不能簡單粗暴地直接：
從上面的互動可以看出，如果這樣實作，資料量一大的話肯定各種問題：
1.資料量大的話rpc執行時間長，有可能HTTP請求會逾時；
2.中間各個網絡節點IO流壓力大；
3.檔案處理有可能記憶體溢出；
4.發生運作時異常機率非常高，分布式事務導緻結果不一緻：RPC那邊已經送出了，但是調用方後面發生異常導緻兩邊不一緻；
5.用戶端響應久，互動差...
那這樣肯定要用異步了，不走異步隊列的話，用定時任務把。處理資料備援在資料庫，定時任務定時去拿資料處理，維護處理結果：
這樣執行速度優化了很多，前端響應也快。但是又怕定時器并發問題，雖然是一個服務，但是單個任務執行慢的話怕下一次觸發定時任務同步造成髒讀，錯誤并發處理。是以了解了下Spring的定時任務，發現Spring的定時任務預設是單線程的，那這樣就不用擔心，不然要加鎖防止并發了。既然涉及到定時任務的并發控制，順便記錄一下比較簡單的設定定時器并發：
一、在定時器上使用@Async注解實作異步任務，并需在啟動類配合加上 @EnableAsync才會生效；
二、 手動設定定時任務的線程池大小：不使用@Async注解，新增啟動代碼配置類：
好了，簡單做一下記錄，雖然初級但是至少培養記錄總結的習慣吧。