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

很不錯(cuò)的分享，學(xué)習(xí)學(xué)習(xí)~

@xylz
呵呵,新手一個(gè),還有很多不理解和理解錯(cuò)的地方.

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

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

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

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

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

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

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