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
[msgTopic:"
+ msg.getTopic()
+ "
msgId:"
+ msg.getMsgId()
+ "
msgContent:"
+ new String(msg.getConent(),"UTF-8")
+ "
msgKey:"
+ 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、建议更新客户端包为最新的包。