RocketMQ使用心得1-消息发送

去年末接触RocketMQ，主要因为官方标注消息必达，项目为支付相关，通过Restful api接收订单存库+推送MQ，再由消费端支付。后期发现即使消息必达，但消息不一定100%发送成功，那么如何判断消息发送成功又成为了一个坑。

消息发送结果SendStatus分4种SEND_OK、FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、SLAVE_NOT_AVAILABLE，理论上如果broker配置同步落盘+同步双写，那么只有SEND_OK才能明确标识发送成功，其它状态为发送失败，但是实际上回执其它3种状态时消息都发送成功。因此改为如果消息发送无异常则认为消息发送成功，然而后期高并发测试中出现了消息发送异常，但是消费端接到了消息，尝试了2种解决方案，最终使用了方案2：

方案1：如果消息发送异常，则数据回滚，同时在消费端增加消息确认，比如订单是否入库，但是存在一个问题，有可能consumer消息接收速度比数据commit更快，那么就会出现消费端先判断数据不再数据库，而后数据才插入，因此方案1不论从性能还是逻辑上都比较差，pass。

方案2（推荐）：api接收订单后入库，不论MQ消息是否发送成，都返回请求成功，无需回滚。增加监听程序，定时把超时未消费（即消息发送失败）的订单补发消息，这个方案相对好在发送消息使用默认配置也可以，可以不加大发消息重试次数和重试超时时长限制，以最快的速度接收订单+存库+推送消息。消息发送失败是比较极端情况，因此监听任务量不大而且执行逻辑非常简单，补发消息就是了。

建议不论使用什么MQ，消息吞吐量和消息必达的测试结果都是扯淡的，加上业务逻辑后就会出现各种各样的坑，如果希望确保消息必达或必发，那么方案2中的监听是一个必不可少的模块。