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


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


    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自动调度)

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

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


  • 相关阅读:
    eclipse部署
    jsp—eclipse配置
    虚拟路径和虚拟主机
    tomcat配置
    初来乍到K
    【转】https://和http://区别
    【转】编码格式
    【转】如何使用瑞萨E10A调试SH系列不带片内FLASH的单片机
    【转】UML
    软考_系统架构师
  • 原文地址:https://www.cnblogs.com/hehe520/p/6147669.html
Copyright © 2020-2023  润新知