基于netty3.x框架的消息处理,需要注意线程池结构的设计

当某类消息过于密集时,会导致其他类型的消息长时间无应答或延迟。

基本结构:server listener --> thread pools --> message handler --> real business processor 。这样的结构会是一个线程池分发所有消息,结构比较简单,但操作密集型消息时,会导致上面的情况发生。


需要改为:server listener -->  message handler --> thread pools --> real business processor,这样的好处就是可根据message handler将不同的消息分发给不同的thread pools,再做后续处理。但设计上较前者复杂不少。


密集型消息和非密集消息,是否需要有序的处理过程,依实际情况而定,与当前结构不冲突 。


你可能感兴趣的:(线程池,netty,消息延迟)