RocketMQ有3种消息类型：普通消息，顺序消息，事务消息。
普通消息的发送方式有3种：可靠同步发送、可靠异步发送和单向发送。
可靠同步发送：同步发送是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。 例如重要通知邮件、报名短信通知、营销短信系统等都可以使用这种方式。
可靠异步发送 ：异步发送是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。发送方通过回调接口接收服务器响应，并对响应结果进行处理。 异步发送一般用于链路耗时较长，对RT响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等，说白了，这种方式如果用的适当，可以提高系统响应速度，提高用户体验。
单向发送 ：单向发送是指发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。如果对数据的可靠性要求不高，丢失了也没关系，如日志收集这种场景，可以采用这种方式发送消息，这种消息发送方式是速度最快的。
顺序消息：顺序消息是消息队列提供的一种严格按照顺序来发布和消费的消息类型。
为什么需要顺序消息，或者说为什么消息需要顺序。如果后一条消息的处理依赖于前一条消息的处理结果，那么按顺序发送消息就是必须的了。
但是生产者发送顺序消息，也不能保证消息能够被顺序消费，它只能够保证消息可以被发送到同一messagequeue中，想要做到顺序的消费消息，还需要消费者的配合。
而生产者是怎么做到顺序发送消息的，可以参考下一个顺序消息的api，如下：
可以发现有个hashKey，类比下Redis集群分片，ElasticSearch的分片路由等，可以知道这个hashKey起到的就是一个路由的作用，比如我们用订单id做为hashKey，那么相同订单就会被发送到同一个messagequeue中了。
事务消息：RocketMQ提供了事务消息，通过事务消息就能达到分布式事务的最终一致。
这个事务消息，主要用来保证分布式事务的最终一致性，这也是分布式事务解决方案之一的基于可靠性消息的最终一致性方案。
使用事务消息的方式发送消息，会有一个半事务消息的状态，半事务消息就是发送方已经成功地将消息发送到了RocketMQ服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，消费者此时是无法消费这个消息的。
投递成功半事务消息后，发送方会执行本地事务，根据事务执行的成功或失败(Commit 或是Rollback)向服务端提交二次确认，服务端收到Commit状态则将半事务消息标记为可投递，订阅方最终将收到该消息，服务端收到Rollback状态则删除半事务消息，订阅方将不会接受该消息。
不过也有特殊情况，比如因为网络问题或者是应用重启的特殊情况下 ，第二次确认没有及时发送给服务端，那么在经过固定时间后服务端将对该消息发起消息回查，消息回查什么，自然是回查之前消息执行事务的状态是成功还是失败或者是还是执行中，那么这些状态通过什么确认呢，这就需要本地消息表了，在一个事务中，一旦本地事务执行结束，也要向本地消息表写入对应的信息，然后发送方就可以根据检查本地消息表来得到本地事务的最终状态再次提交二次确认，服务端仍会按照二次确认的状态来决定是将半事务消息标记为可投递还是直接删除半事务消息。
以上就是RocketMQ3种类型消息的简单理解，而理解作用后，再使用对应api就能更得心应手了。
