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

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

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

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

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

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

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

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

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

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