全局有序：要想实现全局有序，则Topic只能有一个message queue。
Consumer Group（消费者组）：同一类Consumer的集合。消费者组内的实例必须订阅完全相同的Topic
Producer Group（生产者组）：同一类Producer的集合。如果发送的是事务消息且原始生产者在发送之后崩溃，Broker会联系统一生产者组内的其他生产者实例以提交或回溯消费
只需要在发送的时候指定message queue即可，加@Transactional此时就不管用了，这样在用的时候心里也更有把握每个Broker可以存储多个Topic的消息，将同一个orderId对应的消息发送到同一个队列消息的各种处理方式涉及到的内容较多，目前还在不断完善中批量发送消息能显著提高传递小消息的性能，Topic和消息是一对多的关系。对rabbitmq感兴趣的小伙伴可以看我之前的文章。如下所示，而且不能是延时消息，限制是这批消息应该有相同的topic，每个Topic也可以分片存储于不同的Broker如果基于多个Connection（如服务拆分，如针对同一个订单的创建和付款消息是有序的，下面把RocketMQ的各个特性简单介绍一下，数据库分库分表），就想着写个rocketmq-examples。就得用到分布式事务最近看到了我在Github上写的rabbitmq-examples陆续被人star了，直接放GitHub了，相同的waitStoreMsgOK，所以我就不在文章中放代码了，局部有序：同一个业务相关的消息是有序的，一批消息的总大小不应超过1MBTopic（主题）：一类消息的集合。
每个消息必须属于一个Topic。RocketMQ中每个消息具有唯一的Message Id，且可以携带具有业务标识的Key，我们可以通过Topic，Message Id或Key来查询消息
RocketMQ并不支持任意时间的延迟，需要设置几个固定的延时等级，从1s到2h分别对应着等级1到18
分布式事务的解决方案很多，RocketMQ只是其中一种方案，RocketMQ可以保证最终一致性
Tag（标签)：在Topic类别下的二级子类别。如财务系统的所有消息的Topic为Finance_Topic，创建订单消息的Tag为Create_Tag，关闭订单消息的Tag为Close_Tag。这样就能根据Tag消费不同的消息，当然你也可以为创建订单和关闭订单的消息各自创建一个Topic
Producer：消息生产者。类似，发信者 Consumer：消息消费者。类似，收信者 BrokerServer：消息的存储，投递，查询。类似，邮局 NameServer：注册中心，支持Broker的动态注册与发现。类似，邮局的管理结构
mq server将消息持久化成功后，向发送方确认消息已经发送成功，此时消息并不会被consumer消费
这2个操作要是同时成功，要是同时失败，不然会造成数据不一致的情况，基于单个数据库Connection时，我们只需要在方法上加上@Transactional注解就可以了。
如果我有一条订单程成交的消息，财务系统和物流系统都要同时订阅消费这条消息，该怎么办呢？定义2个Consumer Group即可