RocketMq架构以及基本使用

1.为什么要使用mq

在现在分布式架构下，可能很多朋友都会遇到如下问题，我们现在以我们是一个订单服务举例：

1.解耦

订单服务在创建订单成功过后，会通知库存服务扣减库存，发放优惠券，调用第三方物流服务发货等一系列操作，如果采用同步的方式，可能导致接口时延特别高。如果引入mq，可以订单服务执行完自身操作过后，然后将消息以mq的形式通知给第三方服务，完成了服务间的解耦，提高系统的吞吐量。

2.异步通信

比如大数据团队，可能需要根据订单信息去做报表。可以通过监听binlog的方式，通过mq传递给大数据团队。实现了不同团队之间的异步通信。

3.削峰填谷

比如秒杀场景，如果不引入消息中间件，可能让请求压力直接给到数据库。引入mq后，先将请求发送到mq中，然后再慢慢消费，入库，降低了数据库的压力。

2.rocketmq的架构

rocketmq的架构如图所。

2.1 生产者组

是由多个生产者组组成，向broker中发送消息。

2.2 消费者组

也是由业务方多个消费者组成，完成对broker中的业务进行消费。

3.3 NameServer集群

注册中心，类似于zookper，消费者和生产者会与NameServer建立长连接，当需要推送或者消费消息的时候，会从NameServer获取到路由信息。NameServer是一个集群，但是不同的机器之间并不保持联系。同时Broker会将自身信息存储到NameServer上面，并且建立30秒钟的心跳，当NameServer超过120秒没有收到broker的心跳连接后，便会剔除该broker。

3.4 topic

topic是一个逻辑概念，表示不同类型的消息，比如订单系统发送的消息放到orderTopic里面，支付系统发送的topic放在payTopic里面。

3.5 messageQueue

messageQueue是真正存储消息的地方，其实在rocketMq里面，消息是顺序存储到不同文本文件里面的，这些文本文件就是commitLog，并且在存储的时候，会针对里面不同的topic建立不同的索引，这些索引就是consumeQueue，所以消费者在消费的时候，是根据consumeQueue获取到自己在commitLog中的索引位置，然后找到真正需要消费的数据，所以这里consumeQueue其实就是messageQueue。

3.6 broker

broker是存储消息的机器，为了增加吞吐量，所以一般会以集群的方式部署broker，比如部署一个包含broker1，broker2的集群，然后把topicA的一部分数据存储到broker1上，一部分存储到broker2上面，这样消费的时候，就可以在broker1和broker2并行消费。但是这样有个问题，就是某个broker崩溃，会导致部分数据丢失，于是给每个broker以主从方式部署。当主broker挂了，从broker可以替代主broker，这里选取哪个broker作为新主，并且如何进行主动同步，其实是用deledger技术实现的，用的是分布式算法中的raft协议，这个后面会详细讲解。