這個簡單處理方式有很多. 數據庫搞張任務表,放一條記錄,每個節點先取這條記錄(任務狀態是可執行),然后再通過update將value+1并且更新狀態,帶上先前查詢出來的value作為查詢條件,這樣相當于加了一把樂觀鎖,因為數據庫底層是原子的,所以只有一臺機器會更新成功. 這樣就達到目的了. 還有稍微復雜點的是通過zk來維持一把任務鎖,這樣執行任務的只有一臺機器,掛掉后另外一臺機器搶到鎖開始做事情. 當然還有其他方法

很不錯的分享，學習學習~

@xylz
呵呵,新手一個,還有很多不理解和理解錯的地方.

@岑文初
1.這個問題主要在壓力測試的時候發現的,比如并行的任務線程池大小為10,隊列為20,也就是同時能夠提交的任務最大30個,后面SUBMIT或者EXECUTE被拒絕(直接拒絕策略),這確實是符合要求的,但有一個問題是,假設一次請求生成5個左右的并行任務,只要其中一個任務失敗就這次請求失敗,因為線程池一直處于忙碌狀態,所以這5個任務很有可能被部分拒絕,實際上是數量>=2的并行任務都有可能被部分拒絕導致這次請求失敗. 所以我的策略改成主線程來執行了,但我認為有個等待超時會更好.

3.因為主線程得收集到并行任務執行完畢的所有結果才能進行下一步操作(也就是屏障),有N個并行任務,我就實現一個CountDown N次的閉鎖,然后主線程提交完任務后await,任務持有這個閉鎖,執行完任務就 CountDown一下,直到CountDown完畢.異常處理是線程池任務持有主線程實例,發生異常的時候interrupt主線程,主線程響應這個中斷異常,cancel其他任務以及清理資源.

我主要有3個問題
1.并行任務執行的線程池是自己實現的還是使用Concurrent包的線程池?然后線程池的飽和拒絕策略采用的是什么策略?因為Concurrent包中的線程池如果不擴展沒有如同數據庫連接池的等待超時策略,一旦滿了就立刻執行飽和拒絕策略里面的行為,所以你實現的線程池(如果是的話)飽和拒絕策略是否加入了超時特性,或者干脆使用主線程執行?

2.并行執行任務結果需要同步合并的場景中,如果其中某個并行任務失敗,是強行取消其他正常任務,并且回收資源,還是讓其執行完畢?

3.另外通過不斷輪詢隊列中的任務是否完成與通過CountDownLatch的通知,哪種會比較強?至少后者我需要維護閉鎖在異常情景下的行為,否則會導致內存泄露,感覺比較復雜(這是我們一個場景實現的方式).

我們的產品我也把它拆成了一個個handler,再組成一條流水線. 基于事件流轉+pipeline 組合感覺比較合適異步的處理流程,比如網絡通信. 而在同步處理流程里面,用pipeline來拆分任務就足夠了. 但是有一個問題在于各個handler之間傳遞著一個類似總線的數據對象,我一直比較糾結在整個流程里面從始至終都維持一些數據是否有必要?

好像在網絡IO中很有用的一個命令，記下了。
然后能否多分享一些其他有用的網絡命令？