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

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

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

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

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