PDF《消息服务 MNS》

}else{ System.out.println( the queue is empty );

} Message consumer3Msg = queueForConsumer3.popMessage(30);

if(consumer3Msg != null) { System.out.println( consumer3 receive message: + consumer3Msg.getMessageBodyAsRawString());

}else{ System.out.println( the queue is empty );

} // delete the pullTopic. pullTopic.delete();

}catch(ClientException ce) { System.out.println( Something wrong with the network connection between client and MNS service. + Please check your network and DNS availablity. );

ce.printStackTrace();

} catch(ServiceException se) { /*you can get more MNS service error code in following link. https://help.aliyun.com/document_detail/mns/api_reference/error_code/error_code.html?spm=5176.docmns/api_re ference/error_code/error_response */ 消息服务 MNS 最佳实践

3 消息处理时长自适应 如何自适应消息处理时长 背景描述 阿里云MNS消息服务的规范中,每条Message都有个默认的VisibilityTImeout,worker在接收到消息后 ,timeout就开始计时了.如果Worker在timeout时间内没能处理完Message,那么消息就有可能被其他 Worker接收到并处理. Timeout计时的好处是:消息处理完之后需要显式地DeleteMessage,那么如果Worker进程Crash等情 况发生,这条Message还有机会被其他Worker处理. 一些用户会将队列的默认VIsibilityTimeout设置得比较长,以确保消息在被Worker处理完之前不会超时 释放. 问题 但是,在一些应用场景中,我们假设: 队列的VisibilityTimeout是6个小时. A worker接收到了Message M1,但是worker在处理完消息之后,进程发生了Crash或者机器发生了重启. 那么M1这条消息至少在6个小时之后才会被某个Worker接收到并处理.而自己写代码处理Failover的情况的话 ,程序又会变得比较复杂. 目标 在一些即时性要求比较高,并且又希望尽快响应每一条消息的场景下,我们会希望: 队列的 VisibilityTimeout 比较短.比如是5分钟,这样的话,在发生了进程 Crash 之后,最多5分钟 ,之前未处理完的消息就会被某个 worker 接收到并处理. se.printStackTrace();

} client.close();

消息服务 MNS 最佳实践

4 q q q q worker 处理消息的过程中,耗时很有可能超过5分钟,那么消息在被处理的过程中,不能超时. 实现方案 对于这样的场景,我们提供一个BestPractice的C# Demo:(请见附件)具体的做法是,在worker处理消息的 过程中,为消息定期检查是否需要做ChangeVisibility,worker处理完之后依然是主动deleteMessage. 如果有任何问题,欢迎大家在论坛发帖,或者直接加入我们的官方MNS技术支持旺旺群 (群号51222373). 下面是对于程序的几点说明: 运行前需要填写 accessId, accessKey, endPoint. 变量说明: MessageMinimalLife 是消息注册时必须有的最少的 Life 长度.需要这个的原因是,比如 消息 register 的时候已经只剩下 0.1 秒的超时时间了,那么注册进来也来不及 ChangeVisibility 延长生命.所以,MessageMinimalLife 是为了确保 Message 能活到被 ChangeVisibility,用户可以自己根据业务压力来设置. TimerInterval 是Manager 内部的 Timer 的Interval.只需要确保在 Message 到达 MessageMinimalLife 之前,Timer 会被启动就足够了.时间可以设置得比较短(检查得就 比较频繁). QueueMessageVisibilityTimeout 是Sample 里Message 的默认超时时间,是Queue 的属性.Sample 里每次 ChangeVisibility 的时候,会把消息的 VisibilityTimeout 设置为 QueueMessageVisibilityTimeout, 所以它的值需要大于 TimerInterval+ MessageMinimalLife,以确保消息不会超时. MessageTimeout 是Message 在Manager 里面的超时时间,比如某个 worker 卡住了 ,消息在5个小时之后依然没有处理完毕(假设5个小时远远超出消息的正常处理时间),那么Manager 就不会再为 Message 做ChangeVisibility 了,会放任 Message 的Visibility 超时. 流程说明: Worker在ReceiveMessage之后,会先做RegisterMessage,然后处理Message,最后再 调用Manager的deleteMessage. Manager在消息第一次注册进来之后,调用ThreadPool调度一个ChangeVisibilityTask检 查是否需要ChangeVisibility,并且把Message加到内部的messages列表中 Manager内部的Timer,会定时调用Parallel启动 ChangeVisibilityTask检查messages列表 里的所有message 消息服务 MNS 最佳实践