细细审视的你代码：异步消息处理

在工作中经常会碰到需要进行异步消息处理的业务场景，根据消息性质的不同有完全不同的处理方式。

1、消息不独立

不独立的消息通常是有顺序依赖关系，这时消息处理机制将退化为线性队列处理模式，只能由一个消费者去单线程处理消息。

2、消息完全独立

完全独立的消息，可以由多个消费者（线程）并发同时处理，可以达到最大的并发处理能力。

3、消息不完全独立

通常这种情况是，同源消息（来自同一生产者）要求有序，异源消息顺序无关。

这个场景的消息处理会相对复杂点，为了保证同源消息有序，很容易想到对同一来源的消息绑定固定的消费者线程，这样做很简单但存在很大问题。

如果生产者数量很大，绑定线程数可能不够，当然可以复用线程资源，同一线程绑定多个消息来源进行处理，这样做又会有另一个问题：消息源之间的相互影响。

考虑以下场景：

生产者P1产生大量消息进入队列后被分配给消费线程C1处理（C1可能需要处理很长时间），这时生产者P2产生了一个消息，不幸的是也被分配给了消费线程C1处理

那么生产者P2的消息处理将被P1的大量消息给阻塞住，导致了P1和P2之间的相互影响，而且也不能充分利用其它消费线程导致不均衡。

所以，我们必须考虑避免这样的问题。做到消费处理的及时性（尽快）、隔离性（避免相互干扰）、均衡性（最大化并发处理）

在实现中，会有两种模式，比较容易想到的是线程派发模型（PUSH方式），具体做法通常如下：

1. 有一个全局消息派发者，轮询队列取出消息。

2. 根据消息来源，派发给合适的消费线程处理。

派发的算法机制简单的可以类似像基于消息来源的Hash，复杂的可以根据各个消费线程的当前负载，等待队列长短、消息的复杂度进行综合分析选择派发。

简单Hash肯定会碰到上述场景描述的问题，但复杂派发计算很明显实现起来非常麻烦和复杂，效率也不一定好，在均衡性方面也很难做到十分平衡。

第二种模式采用PULL方式，线程按需拉取，具体做法如下：

1. 消息源直接将产生的消息放入对应该源的临时队列中（如下所示每个session代表一个不同的消息来源），再将session置入一个阻塞队列通知线程处理

2. 多个消费线程同时轮询队列，争抢消息（保证只有一个线程取到

3. 检查队列指示器是否正被其他线程处理（实现时需要在线程级别基于同源消息的检测同步）

4. 若未被其他线程处理，则在同步区置处理中指示状态，退出同步区后对临时队列中的消息进行处理

5. 处理完成后，最后再次进入同步区置处理指示状态为空闲

下面用一段代码来描述下消费线程处理流程：

public void run() {
	try {
		for (AbstractSession s = squeue.take(); s != null; s = squeue.take()) {					
			// first check any worker is processing this session? 
                        // if any other worker thread is processing this event with same session, just ignore it.
			synchronized (s) {
				if (!s.isEventProcessing()) {
					s.setEventProcessing(true);
				} else {
					continue;
				}
			}
					
			// fire events with same session
			fire(s);
					
			// last reset processing flag and quit current thread processing
			s.setEventProcessing(false);
					
			// if remaining events, so re-insert to session queue
			if (s.getEventQueue().size() > 0 && !s.isEventProcessing()) {
				squeue.offer(s);
			}
		}
	} catch (InterruptedException e) {
		LOG.warn(e.getMessage(), e);
	}
}

如上，采用PULL模式消费线程的实现就变得相对简单，尽量最大化并发能力（线程争抢，CPU自动调度）

保证了均衡（线程一旦空闲自动去拉取消息，不再需要了解不同消息类型处理的复杂度）

隔离不同来源消息的相互影响（只要消费线程没有满负荷，消息总是能得到及时处理）