1、Producer使用指南--发送消息注意事项
1、正常情况下一个业务系统尽可能用一个Topic,消息子类型用tags来标识,tags可以由业务系统自由设置。只有发送消息设置了tags,消费方在订阅消息时,才可以利用tags在broker做消息过滤。
MQCPMessage msg = new MQCPMessage(); // 初始化消息对象
message.setTags("TagA"); // 设置消息TAG
2、每个消息在业务层面的唯一标识码,要设置到keys字段,方便将来定位消息丢失问题。服务器会为每个消息创建索引(哈希索引),应用可以通过topic,key来查询这条消息内容,以及消息被谁消费。由于是哈希索引,请务必保证key尽可能唯一,这样可以避免潜在的哈希冲突。
MQCPMessage msg = new MQCPMessage(); // 初始化消息对象
message.setTags("TagA"); // 设置消息TAG
String orderId = "20034568923546"; // 订单Id
message.setKeys(orderId);
3、消息发送成功或者失败,要打印消息日志,务必要打印sendresult和key字段。
4、send消息方法,只要不抛异常,就代表发送成功。但是发送成功会有多个状态,在sendResult里定义
5、对于消息不可丢失应用,务必要有消息重发机制。例如如果消息发送失败,存储到数据库,能有定时程序尝试重发,或者人工触发重发。
2、Consumer使用指南--消费端去重
RocketMQ无法避免消息重复,所以如果业务对消费重复非常敏感,务必要在业务层面去重,有以下几种去重方式:
1. 将消息的唯一键,可以是msgID,也可以是消息内容中的唯一标识字段,例如订单Id等,消费之前判断是否在Db或Tair(全局KV存储)中存在,如果不存在则插入,并消费,否则跳过。(实际过程要考虑原子性问题,判断是否存在可以尝试插入,如果报主键冲突,则插入失败,直接跳过)msgId一定是全局唯一标识符,但是可能会存在同样的消息有两个不同msgId的情况(有多种原因),这种情况可能会使业务上重复消费,建议最好使用消息内容中的唯一标识字段去重。
2. 使用业务层面的状态机去重
5、如何判断发送消息是否成功?
客户端Producer调用send消息方法,只要不抛异常,就代表发送成功。但是发送成功会有多个状态,在sendResult里定义。
返回状态 | 状态释义 |
SEND_OK | 消息发送成功 |
FLUSH_DISK_TIMEOUT | 消息发送成功,但是服务器刷盘超时,消息已经进入服务器队列,只有此时MASTER服务器宕机,消息才会丢失 |
FLUSH_SLAVE_TIMEOUT | 消息发送成功,但是服务器同步到Slave时超时,消息已经进入服务器队列,只有此时SLAVE服务器宕机,消息才会丢失 |
SLAVE_NOT_AVAILABLE | 消息发送成功,但是此时SLAVE不可用,消息已经进入服务器队列,只有此时SLAVE服务器宕机,消息才会丢失 |
目前MQCP测试和生产环境集群都采用两主两从共4台Broker机器,针对大部分业务系统来讲,只要MQCP没有抛出异常,可以默认消息已成功发送。建议业务系统针对发送消息后所有非SEND_OK状态的消息,打印Warning日志,并在运营端设置对应的监控规则,及时发邮件提醒。
6、如何判断消费消息是否成功?
客户端Consumer在MQCPMessageListener中实现pushMessage(),遍历并处理消息后会返回给MQCP端消费的状态,状态只有消费成功或者消费失败两种状态。
消费状态 | 状态释义 |
CONSUME_OK | 消费成功 |
CONSUME_FAIL | 消费失败 |
7、消费端如何实现定时消费?
在某些业务场景下,消费端希望在业务低峰(例如半夜12点后)时开始从MQCP拉取消息,在业务高峰期前关闭掉消费功能,以此来降低系统负载。这种类似场景涉及到如何在不停业务服务的场景下,多次的开启和关闭MQCP消费服务。
MQCP的消费者本身是可以多实例初始化的,每个实例的消费者服务开启和关闭也是独立的,所以可以很良好的支持定时消费的场景。
如果业务系统有类似的需求,我们建议:
1. 业务系统本身需要添加功能开关,支持配置化的方式来开启或关闭消费服务。其实现本身比较简单,就是调用MQCP消费者的start || shutdown方法。必要时需要对方法添加上层逻辑封装,来实现定制化的需求。
2. 调用完consumer对象的shutdown方法后,不要立即初始化下一个consumer对象并启用服务,建议至少延迟几秒种,等相关的资源回收完毕。
3. 完善业务端开启或关闭消息服务的日志,方便后续运维处理问题。
4. 具体实现方式,可以参考下面TestTimedConsumeImpl类。
import java.io.UnsupportedEncodingException; import java.util.ArrayList; import java.util.List; import java.util.Properties; import com.paic.mqcp.client.MQCPFactory; import com.paic.mqcp.client.common.MQCPException; import com.paic.mqcp.client.common.MQCPMessageListener; import com.paic.mqcp.client.consumer.MQCPConsumer; import com.paic.mqcp.client.dto.MQCPMessage; import com.paic.mqcp.client.dto.MQCPMessageFilter; import com.paic.mqcp.client.util.MQCPConstant; import com.paic.mqcp.client.util.MQCPConsumeStatus; import com.paic.mqcp.common.consumer.ConsumeFromWhere; /** * 模拟业务系统需要在不停应用的场景下,开启、关闭接受消息服务 * * @author WUJING754 * */ public class TestTimedConsumeImpl { /** 属性对象 */ private static Properties p = null; /** * 获取属性值对象 * * @return Properties */ public static Properties initialProperties() { p = new Properties(); // 业务系统可以从配置文件中取出该属性,demo中写死的 p.setProperty(MQCPConstant.NAME_SERVER_ADDRESS, "10.20.22.148:9876;10.20.22.149:9876"); // 消费者ID,业务系统需要在MQCP-ADMIN中注册,否则无法正常发送消息 // demo中已经初始化好了的,后续请联系MQCP开发注册系统 p.setProperty(MQCPConstant.CONSUMER_ID, "CID_PARP_TEST_DEFAULT"); // INSTANCE_NAME属性建议业务系统不设置,用默认的即可 //p.setProperty(MQCPConstant.INSTANCE_NAME,"_PACP"); return p; } public static MQCPConsumer initialConsumer(){ MQCPConsumer pushConsumer = null; try { // 初始化过滤对象 MQCPMessageFilter mqcpFilter = new MQCPMessageFilter(); List<String> list = new ArrayList<String>(); // 设置tag // tag的作用是过滤消息,如果设置改值,MQCP只会取出发送消息时设置了该tag值的消息 // 需要注意的是同一CID下的多个应用实例需要设置为同样的tag列表来过滤消息,以保证消息不会被过滤取走但未被业务系统处理 list.add("testByWUJING754"); mqcpFilter.setTags(list); // 初始化MQCPPushConsumer并指定为集群消费(消息只会被消费一次,无论应用的实例有多少个) // PUSH消费模式下,客户端包会启动后台线程不断的从MQCP中拉去消息(准实时方式,毫秒级延时) // 业务系统收取到消息后,需要实现MQCPMessageListener,来处理消息 pushConsumer = MQCPFactory .createConsumer(initialProperties()); // 设置第一次CID消费消息的时间点,这里设置从最后的消息开始获取 // 如果不设置该值,默认是队列的最开始出消费消息 pushConsumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET); // 订阅 T_PAFA5_LOG_P 主题的消息(创建topic需要在MQCP-ADMIN中,如需创建请联系MQCP开发) pushConsumer.subscribe("T_PARP_TEST_DEMO", mqcpFilter, new MQCPMessageListener() { @Override public MQCPConsumeStatus pushMessage( List<MQCPMessage> messageList) { // 监听到有消息抵达后,业务系统需要遍历messageList对象,来获取消息 // messageList的默认大小为1,即消息是一条一条的推送到客户端的 for (MQCPMessage msg : messageList) { // 消息明细 MQCPMessage对象 // 建议业务系统将从消息平台拉取消息和处理消息的逻辑解耦, // 在consumer监听器中只监听到消息,建议简单的将获取的消息解析存储,然后返回 MQCPConsumeStatus.CONSUME_OK, // 后端可以异步来处理接收到的消息 try { System.out.println("###########receive message\n[msgTopic:" + msg.getTopic() + "\nmsgId:" + msg.getMsgId() + "\nmsgContent:" + new String(msg.getConent(),"UTF-8") + "\nmsgKey:" + msg.getKey() + "]"); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } } return MQCPConsumeStatus.CONSUME_OK; } }); } catch (Exception ex) { ex.printStackTrace(); } return pushConsumer; } /** * 入口 * @param args */ public static void main(String[] args) { // 初始化一个pushConsumer对象 MQCPConsumer pushConsumer = initialConsumer(); // 启动该consumer对象,开始消费消息 startConsumingMsg(pushConsumer); // 业务系统不断收取消息,处理消息过程中... // 根据业务需要,可以调用stopConsumingMsg()方法来停止收取消息 stopConsumingMsg(pushConsumer); // 主线程休眠30秒 try { Thread.sleep(30000L); } catch (InterruptedException e) { e.printStackTrace(); } // 模拟业务系统再次初始化一个consumer对象 pushConsumer = initialConsumer(); // 启动consumer,开始收取消息 startConsumingMsg(pushConsumer); // 业务系统不断收取消息,处理消息过程中... // 业务系统根据需要,停止取消息服务 stopConsumingMsg(pushConsumer); } /* * 启动传入的消费者对象 */ public static boolean startConsumingMsg(final MQCPConsumer pushConsumer){ boolean flag = true; try { pushConsumer.start(); System.out.println("-->start consumer success."); } catch (MQCPException e) { System.out.println("-->start consumer fail due to " + e.getMessage()); e.printStackTrace(); flag = false; } return flag; } /* * 关闭传入的消费者对象 */ public static void stopConsumingMsg(final MQCPConsumer pushConsumer){ pushConsumer.shutdown(); System.out.println("-->shutdown consumer success."); } }
9、客户端生产者是否有消息重发机制?
(摘至RocketMq官方文档)
RocketMq消息发送失败如何处理,Producer的send方法本身支持内部重试,重试逻辑如下:
1. 至多重试5次。
2. 如果发送失败,则轮转到下一个Broker。
3. 这个方法的总耗时时间不超过sendMsgTimeout设置的值,默认5s。
所以,如果本身向broker发送消息产生超时异常,就不会再做重试。
以上策略仍然不能保证消息一定发送成功,为保证消息一定成功,建议应用这样做:如果调用send同步方法发送失败,则尝试将消息存储到db,由后台线程定时重试,保证消息一定到达Broker。
上述DB重试方式为什么没有集成到MQ客户端内部做,而是要求应用自己去完成,我们基于以下几点考虑
1. MQ的客户端设计为无状态模式,方便任意的水平扩展,且对机器资源的消耗仅仅是cpu、内存、网络。
2. 如果MQ客户端内部集成一个KV存储模块,那么数据只有同步落盘才能较可靠,而同步落盘本身性能开销较大,所以通常会采用 异步落盘,又由于应用关闭过程不受MQ运维人员控制,可能经常会发生kill -9这样暴力方式关闭,造成数据没有及时落盘而丢 失。
3. Producer所在机器的可靠性较低,一般为虚拟机,不适合存储重要数据。
综上,建议重试过程交由应用来控制。
10、客户端消费者是否有消息重发机制?
(摘至RocketMq官方文档)
消息重试机制如下:
注意:重试的消息,MsgKey不变,MsgId会变。
11、业务消费端没有取到消息,如何去定位问题?
正常情况下生产者发送消息到MQCP,消息被投递到消费端的延时应该在毫秒级。如果消费端迟迟没有收到消息,建议采用下面的步骤来排查问题:
1、 获得消息的消息ID或者KEY,去MQCP-ADMIN的消息查询模块,根据自己的消费者ID找到其对应的消费状态。
2、 常见的投递状态有:
SUBSCRIBED_AND_CONSUMED | 订阅了,而且消费了(Offset越过了) |
SUBSCRIBED_BUT_FILTERD | 订阅了,但是被过滤掉了 |
the consumer group[***] not online | 订阅了,但是消费者未启动 |
SUBSCRIBED_AND_NOT_CONSUME_YET | 订阅了,但是没有消费(Offset小) |
UNKNOW_EXCEPTION | 未知异常 |
注: SUBSCRIBED_AND_CONSUMED状态,表示消息已被正常消费掉,如果此时有异常,需要业务系统检查日志,分析看看是否因为解析消息时有异常,导致消息未被正确处理。
SUBSCRIBED_BUT_FILTERD状态,需要业务系统检查初始化Consumer对象时传入的TagList是否和生产者定义的tag匹配。
SUBSCRIBED_AND_NOT_CONSUME_YET状态,可能的原因是由于消息有积压,消息还未被取走,可以稍等几十秒再去查询一下状态。
the consumer group[***] not online状态,表示对应CID的消费者还未正确启动。业务系统需要检查消费者是否已启动,如果已启动请检查是否启动时有报错。有可能相关的配置项配置错误,导致consumer启动时校验失败。
UNKNOW_EXCEPTION表示消息平台有异常,请联系MQCP开发同事。
13、如何避免接收到的消息是乱码?
对于生产者来说,建议将消息body转为byte数组时显示指定为UTF-8编码。对于消费者来说,建议在接收到消息后将byte数组转为String时指定UTF-8编码。这样可以避免因为消息body中有中文或者特殊字符,消费端解析时乱码,进而造成消息解析失败。
Example of producer
MQCPMessage msg = new MQCPMessage();
msg.setConent("test msg body".getBytes("UTF-8")); // 生产者组装消息body时指定urf-8编码
Example of consumer
14、MQCP中的消息标签(tag)如何使用?
在消息中间件实际的使用场景中,消费者只需要消息队列中的部分消息,其余消息希望默认不被接收,直接丢弃掉。针对类似这种场景 ,MQCP提供通过合理使用消息标签(Tag)的方式来实现消费端灵活过滤队列中消息的功能。
实现方式如下:
1、 生产者和消费者双方约定消息标签具体的设置值及其代表的含义。
2、 生产者在发送消息时,组装消息对象的时候,需要给对应消息设置正确的消息标签。
MQCPMessage msg = new MQCPMessage();
//设置过滤标签---大小写敏感
msg.setTag("SystemTag");
3、 消费者在组装消费者对象时,需要正确设置消息过滤的过滤器
MQCPMessageFilter mqcpFilter = new MQCPMessageFilter();
List<String> list = new ArrayList<String>();
// 设置tag
// tag的作用是过滤消息,如果设置改值,MQCP只会取出发送消息时设置了该tag值的消息
// 需要注意的是同一CID下的多个应用实例需要设置为同样的tag列表来过滤消息,以保证消息不会被过滤取走但未被业务系统处理list.add("SystemTag");
mqcpFilter.setTags(list);
上述生产端、消费端的实现代码具体可查阅MQCP官网提供的Demo。
16、The consumer’s subscription not exist报错?
现象:业务系统开发环境报异常:The consumer’s subscription not exist,检查消费者状态,多台实例在线,检查消息消费情况,消息一直不被消费,状态为:SUBSCRIBED_AND_NOT_CONSUME_YET(订阅未消费)。
原因:业务系统之前已经接入过MQCP,且开发环境有多个开发人员在同时进行开发,多个主机同时连接MQCP,本次该consumer新增了1个订阅关系(subscription-A),但业务系统只有1个同事(小Y)的代码才新增了订阅关系,其他几个开发人员的代码没有配置,一旦他们的consumer启动后,给broker保持通信时发送的订阅关系中,并没有subscription-A,broker会remove该订阅关系,因此小Y的consumer启动后,与broker通信时发现没有subscription-A,就会报:The consumer’s subscription not exist。
解决方案:1、不同的cid,订阅不同的topic,避免同一个cid订阅多个topic
2、业务系统开发环境,只开发相关功能的主机才启动consumer
17、业务系统消费端两种常见的错误实现?
18、申请生产环境mq消息查询权限
请使用IE浏览器,在itsm系统申请对应的权限,通道如下:
IT权限管理-申请->平安科技_消息协作平台监控应用(MQCP_ADMIN)=>帐户管理组
19、测试环境admin平台查询消息已消费,但消费端未查询到消息
同一个消费者是集群消费模式,在测试环境中,只想在某一个环境测试MQ功能,需要每个环境配置不同的CID。比如某系统测试环境有多套环境:STG1和STG2环境,测试人员正在STG1测试,如果两个环境的CID相同,则消息有可能就被STG2取走,测试人员在STG1上查不到该消息。
解决方法:
1、若为刚新增的发布订阅关系,请联系MQCP同事申请给每一个环境配置独立的CID,并创建发布订阅关系
2、若每个环境都申请了独立的CID,请检查是否其他某个环境使用了该环境的CID
20、java.lang.reflect.InvocationTargetException告警
业务系统引用客户端包在1.0.15之前版本在启动时可能会出现该异常,不影响消息的收发,1.0.15的客户端版本修复了该问题
解决方法:
更新客户端包为最新的版本,最新包版本可在包库查询。客户端包不断在迭代优化,建议业务系统及时更新客户端包。客户端包每个版本更新内容可在官网“相关文档---CLIENT包版本线”查询。
需注意:客户端包在1.0.20优化了发布订阅关系的校验方式,配置文件的配置项有变化,从原来的name_server_address、cluster_id
、virtual_account变为了:server_address、virtual_account,具体请查阅demo
21、服务启动时报错:MQCP_CLIENT->Initial cache failed,no cache message received after waiting for 90s
客户端在重启的时报错初始化发布订阅关系缓存数据失败。
解决方法:
1、检查是否新增了配置文件:mqcp_client.properties,需新增
2、检查mqcp_client.properties配置文件,客户端版本为1.0.20之前的版本,需检查name_server_address、cluster_id的值是否正确,前后是否包含空格,检查virtual_account配置的虚拟用户是否与admin平台配置的一致,客户端版本为1.0.15之前的,还需在代码里新增name_server_address的配置:p.setProperty(MQCPConstant.NAME_SERVER_ADDRESS,"不同环境配置不同的nameserver地址" ); 客户端版本为1.0.20及之后的,需要检查server_address、virtual_account是否正确,是否包含空格。
3、建议更新客户端包为最新的包。