问：顺序消息实现原理？
答：取模运算，MessageQueueSelector获取Topic中的指定的Broker

问：事务消息实现分布式事务的案例？
答：
转账：先扣钱再加钱；
正常流程：发送准备消息，不能被消费，生产者执行扣钱，扣钱成功，发送成功消息，原先的准备消息就可以被消费，消费者订阅到消息，做加钱动作；
异常情况1：发送准备消息失败，不会执行扣钱动作；
异常情况2：扣钱失败，准备消息不会被消费，没有关系；
异常情况3：扣钱成功，发送成功消息丢失，通过消息回查，检查扣钱事务结果失败则将准备消息转回滚消息；如果扣钱事务执行成功，那么补偿一条成功消息；
异常情况4：消费者端，加钱失败；这种情况无法将整个大动作回滚，因为扣钱这个动作是原子性的，消息队列模式下不能保证所有动作原子性，追求最终一致性；加钱失败，重试、异步补偿，消费者不要响应消费成功，再次消费触发加钱动作；消息队列模式只能保证上游消费者端能够去执行；看场景吧，转账也不是实时的，或者像加积分成功率比较高的适合；

问：事务消息实现原理？
答：
TransactionMQProducer：事务消息发送者；
TransactionListener：事务回调检查器，绑定至TransactionMQProducer；
TransactionMQProducer调用SendMesangeInMessage方法，发送准备消息，发送成功触发TransListener的executeLocalTransaction方法；定期执行checkLocalTransaction做回查；
生产者过程：
1、producer发送prepare消息给mq服务器
2、如果消息发送成功，执行本地事务，同时将消息transactionId与业务操作一并入库，方便后续事务回查
3、根据本地事务执行状态，决定是否对prepare消息进行提交/回滚；

存储提交过程：

  1. PROPERTY_TRANSACTION_PREPARED事务消息给该属性标记为true；
  2. 调用putHalfMessage方法进行存储
  3. 备份原消息QueueID，将该条准备消息的queueID设置为0，防止被消费
  4. 提交就是取出消息原来的topic queueid，进行发送存储，可以被消费

回查过程：
1.TransactionalMessageCheckService的check方法
2.对消息的存储时间和事务超时时间判断，判断超时那么查询消息对应事务的状态，状态成功则补传成功；

问：延迟消息实现原理？
答： Broker将延时消息以SCHEDULE_TOPIC_XXXX为topic名称将消息进行持久化，RocketMQ提供了定时任务服务ScheduleMessageService，通过定时任务的方式不断的读取topic为SCHEDULE_TOPIC_XXXX何queueId为延时等级的消息进行消息还原处理，这样消息被还原之后消费者就可以拉取消息了