rocketmq简单运用

此篇目的在于检录记录rocketmq的学习过程，学习中参考了该篇博客写的很详细

[github项目地址] https://github.com/htp123/RocketMqDemo.git

服务启动过程:
namesrv—>start mqnamesrv.cmd
broker —>start mqbroker.cmd -n 127.0.0.1:9876
admin —>start mqadmin

[rockermq-console]
console—> java -jar …*.jar
浏览器：http://localhost:8080，控制台中的信息应该都可以使用admin命令查看

1、start入门：
启动producer过程中，报错【No route for this topic】，上网查了一下，在启动broker服务时加上autoCreateTopicEnable=true参数就可以了。但这个不是推荐的方法，网上说启动时设置为false，在代码中做处理。这个问题后续学习过程中再细化。

2、filter消息过滤：
按照网上的例子，最开始卡了好久，生产者可以发布消息，但是消费者始终实现不了过滤，控制台中只能看到producer产生的消息记录数，consumer消费记录数始终为0。后来看了一下过滤类的实现，发现自己的match方法和案例中的参数不一样
案例：

public boolean match(MessageExt messageExt）{...}

自己：

  public boolean match(MessageExt messageExt, FilterContext filterContext) {...}

点进filterContext中看到了所具有的功能

public class FilterContext {
    private String consumerGroup;

    public FilterContext() {
    }

    public String getConsumerGroup() {
        return this.consumerGroup;
    }

    public void setConsumerGroup(String consumerGroup) {
        this.consumerGroup = consumerGroup;
    }
}

理解为需要指定消费者组，所以在自己的match中增加了setConsumerGroup调用，然后终于看到了过滤后的消息。

3、order顺序消费：
producer按照tags将生成的消息放到指定的队列中去，消费者打印出的消费记录完全按照顺序。这里也可以借用上面的过滤器，实现消息过滤。

4、transaction事务消费：
此处提到了中控、本地事务、回调检查点的概念，在中控中指定本地事务处理类和回调检查类。

网上看到一段时序图和对应的解释，觉得挺好的，贴在这里

1.0、 Producer发送消息到RocketMQ，这条消息我们暂且称之为message1 并且是transaction状态的事务消息。
1.1、MQ把message1存入数据库，并且是状态是prepared。
1.2、RocketMQ回调Producer中的本地事务。（本地事务由三个状态COMMIT_MESSAGE、ROLLBACK_MESSAGE、UNKNOW）。 
1.2.1 、本地事务处理完成后，无论成功还是失败都会有一个状态，如果成功的话，Producer就会发送COMMIT_MESSAGE状态表示确认消息到RocketMQ上。
1.2.2、然后把message1这个消息存储到consumer queue中，并在数据库中把这条prepared的消息标记为commited。
1.2.3、这条消息就被Consumer消费了。
1.3.1、如果Producer的事务处理返回了一个UNKNOW状态。因为broker会定时的去扫描数据库，如果数据库中的数据状态是commited的，那么就清除这条数据。
1.4、如果数据库中数据的状态还是prepared的。那MQ就会主动的去调用Producer中的check方法。
1.5.1、check方法再去查本地的数据库看有没有减钱，如果没减钱的话就rollback，
1.6.1、rollback后Producer又发了一条ROLLBACK_MESSAGE给MQ。
1.7.1、MQ收到这条消息后，就会把MQ的数据库中对应的prepared数据给清除掉。那么这条数据也就不会被Consumer端消费了
1.5.2、check方法查本地数据库看有没有减钱，如果减钱了。 
1.6.2、会给MQ发送一个COMMIT_MESSAGE。 
1.7.2、MQ还会去查自己的数据库，然后把数据库中对应的数据给清除掉

个人理解为，MQ库中，commited消息则会被broker扫描时清楚。
而只有第一种实时的commit状态，会被消费者消费。对于这一点刚开始有些不太理解，若是最后库中减钱了，那就应该发送到队列中通知消费者消费吧？

测试后发现unknown状态的事务，消息并未到达消费者。最终理解为，未发送至消费者的账务，最终用对账来解决。

5、推送、拉取，消息回溯，点对点/广播