雨过，云过

引：在前面的源码分析中，我们总是能在很多地方看到对于事务消息特别的逻辑，这次我们终于可以讲一下啦！同时对利用消息队列来实现分布式事务感兴趣的同学也是不可错过的！

引：在前面的源码分析中，我们总是能在很多地方看到对于顺序消息特别的逻辑，这次我们终于可以讲一下啦！

引：我恨自己当有问题出现时，没有立刻去把握它！今天看了很多关于Mysql索引优化器的东西，但是没有拿到结果！留下一些链接，希望下次出现索引优化的问题或者慢查询的问题，自己能好好分析一波！

引：前面讲到了Broker对于不同的消息有自己不同的Processor，对于PushConsumer的Pull请求的时候，它对应的就是PullMessageProcessor~

引：前面我们说过了Producer和Consumer是如何发送消息的，当我们了解完Broker的消息存储之后，我们就可以看看Broker是如何接收发来的消息啦~

引：消息存储对于一个消息队列来说是肯定要有的，在RocketMQ中，Broker将消息存储抽象成MessageStore接口，我们也将从这里入手~

引：前面讲了NameServer，Producer，Consumer，现在终于轮到Broker了，对于一个消息队列来说，Broker是当仁不让的核心~

引：当消息达到Broker之后，就等着Consumer去consume了呀~

引：2019 年 1 月，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。为了打造更中立、更开放、生态更加丰富的分布式事务开源社区，经过社区核心成员的投票，大家决定对 Fescar 进行品牌升级，并更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。

引：使用MQ，第一步构造Producer，然后就可以开始发送消息啦！