标签：
应用场景:
典型的生产者-消费者模式, 目前虽已实现,但存在一些问题,准备更换成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的方式实现, 如园友看完上述处理流程有比较好的建议, 一定要多多指教.
标签：
原文地址：http://www.cnblogs.com/mutpay/p/5674149.html
