zoukankan      html  css  js  c++  java
  • MSMQ使用

      应用场景:

      典型的生产者-消费者模式, 目前虽已实现,但存在一些问题,准备更换成MSMQ.

      多个生产者(producer)应用从业务平台拉取订单放入队列应用(QueueManager)(自己实现),

      多个消费者(consumer)应用从队列应用中每次取出1笔订单进行处理,处理完成后直接向业务平台返回订单结果.

      业务性质要求实现的细节:

      1. consumer因涉及硬件设备,数量有限,并且每次仅能处理1笔订单,但是要尽量满载运行.

        满载运行意味着QueueManager要有待处理的订单给consumer去处理,当然前提是producer生产力足够强.

      2. consumer优先处理大面值订单,确认没有合适面值订单的情况下,依次类推100元->50元->30元->20元

      3. QueueManager中超过2min中仍未处理的订单要停止处理,并向业务平台返回最终结果.

        因为consumer要优先处理大面值订单,所以小面值订单就存在超时的情况.

      目前运行的实现流程:

      1. 因受限于consumer的消费能力,仅使用了1个producer从业务平台拉取订单放入QueueManager.

      2. QueueManager中按照订单面值声明了4个队列,每个面值对应1个队列,在接收到producer传送的订单后,按照订单面值放入相应的队列.

      3. consumer在处理完订单后向业务平台返回订单结果,并间隔指定时间后,向QueueManager发送请求,表示当前consumser空闲了,可以处理订单了.

      4. QueueManager接收到consumer的请求后,按照面值从大到小遍历4个队列,如取出订单则跳出遍历,把订单异步给consumer.

      5. QueueManager自启动后就开了一个监控订单超时的线程,按照面值从小到大遍历4个队列,如有超时订单,则跳出遍历,把订单结果返回给业务平台.

      存在的问题:

      1. 向业务平台返回订单结果的操作不能集中管控,在交互过程中若网络异常,就会出现不能把订单结果返回发业务平台的情况.

      2. 人工介入在业务平台处理订单情况较多,故QueueManager未做持久化处理,也就是说如果队列应用挂掉,会有一批订单卡住无法处理.

      3. consumer处理完订单向QueueManager请求新订单,然后队列应用异步新订单的处理方式太繁琐.

      最近正在规划更换成MSMQ的方式实现, 如园友看完上述处理流程有比较好的建议, 一定要多多指教.

  • 相关阅读:
    闲谈:价值、服务、时间、用户体验、美、过度开发
    笔记:Sublime Text 3
    快速切换目录命令go
    miniPy for CentOS 5/6
    用Fabric实现小批量的自动化上线
    异步多线程C/S框架gko_pool
    Reboot分享第三期(已结束)
    Reboot分享第二期(已结束)
    Reboot分享第一期(已结束)
    iptables从入门到精通
  • 原文地址:https://www.cnblogs.com/iot1024/p/5674149.html
Copyright © 2011-2022 走看看