由于公司用户行为数据使用了阿里的4.0系列rocketmq实例作为实时数据计算的消息中间件,所以我们需要对接rocketmq获取数据进行计算落库，由于各种原因，其中最主要的原因是由于不是自己直连阿里的mq，通过其它部门封装好的接口，以及本部门实时计算处理框架的限制导致后续使用mq的问题出现，为了解决只能重构部分代码，不想你们遇到同样的大坑，从而想写下这篇mq使用总结，为这次血的教训留下一点回忆，也希望能够对准备使用阿里mq的程序猿有一点点帮助。
阿里mq的具体细节以及特性这里就不讨论展开了，这里主要说明在使用过程中我们遇到使用http和tcp两种协议问题。
-
http协议
提供了java,go,python,node.js,php,c#,c/c++的sdk，选择比较丰富，不过http协议消费者只支持pull模式。
http协议采用XML序列化，因此消息的属性、内容、Tag、Key等必须符合XML规范，或者上报、拉取消息会报错，如包含特殊字符建议消息提进行编码传送和接收。
http协议消费组有一个很弊端的缺陷，就是不支持消费重置位点，也就是想消费之前的消息是不可能的。
http协议消费组的消息堆积获取接口返回数据是错误有问题的，mq实例总图标也是错的，只有点进消费组里面才能看到正确的消息堆积数量，如果自己需要做消息堆积监控告警使用阿里的接口是不准确的。
消息消费响应时间30秒。
-
Tcp协议
只提供了java,c/c++,.net的sdk，支持的开发语言比http少。
使用该协议消费组使用这个不会出现特殊字符报错问题。
标准版只支持消息推模式，不支持拉模式，要加w升级成铂金版以上才能支持拉模式。
支持消费位点重置，消息积压数据准确。
消息消费响应时间30秒。
TCP协议的客户端和HTTP协议的客户端之间是可以实现消息收发，但是由于TCP不需要符合XML规范，所以如果两种混用，HTTP拉取消息端可能会存在
-
图表对比
 |
||||||
-
结论
该总结适用于4.0系列商用的阿里mq，mq具有一些特性，比如延时消息，定时消息，并且吞吐率很高，所以可能会被一些业务所需要，如果需要用到，编程语言没有限制的话，这边还是建议消息生产端跟消费端都是用tcp协议，从消费速度，还是消息积压监控准确性，以及具有消费位点重置这几个方面都必须选择这个，如果想要了解更多细节，可以去阿里的官方文档看，附上地址：
https://help.aliyun.com/product/29530.html