这个简单处理方式有很多. 数据库搞张任务表,放一条记录,每个节点先取这条记录(任务状态是可执行),然后再通过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中很有用的一个命令，记下了。
然后能否多分享一些其他有用的网络命令？