第一章:初识RocketMQ

MQ（Message Queue）它本质上是一个消息队列，既然是队列那么代表着先进先出(FIFO)的原则。只不过队列中存放的内容是一个被打包好的一个“消息”。它还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种很常见的上下游的消息通信服务。使用MQ消息发送上游只需要依赖MQ，不用依赖其他服务。

​ 如果订单系统最多能处理一万次订单，这个处理能力在正常情况下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作一下打到系统上，这个时候系统根本处理不了，还可能导致系统直接宕机。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比无法下单的体验要好。

​ 如一个电商应用中有订单系统、物流系统、库存系统、支付系统等。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出现了故障，都会造成下单操作异常。如果我们使用基于消息队列的方式后，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存缓存在消息队列中，用户下单操作还是可以正常完成。等到物流系统恢复后，继续处理订单信息即可，在这之中，用户也感受不到系统出来故障，提升系统的可用性。

​ 如果一个A请求发送到服务器B然后完成，需要花费很长时间执行，但是A需要知道B什么时候可以执行完成，以前做法一般有两种方式：A过一会发一个请求，去询问B执行完了没；或者A提供一个callback api，B执行完之后调用api通知A服务。其实这两种方式都不太优雅，使用消息队列，可以很方便的解决这个问题，A调用B服务后，只需要监听B处理完成的消息，当B处理完后，会发送一条消息给MQ，MQ会将此消息转发给A服务。这样A服务既不用循环调用也不用提供回调API。同样B服务也不用做这些操作。

RocketMQ 下载地址

unzip -d /opt/environment/  rocketmq-all-4.9.2-bin-release.zip

启动NameServer

# 1.启动,进入到bin目录下
nohup sh ./mqnamesrv &
# 2.查看启动日志
tail -f ~/log/rocketmqlogs/namesrv.log

使用 jps 命令查看

启动Broker

#1.启动,进入到bin目录下
nohup sh ./mqbroker -n localhost:9876 &
#2.查看启动日志
tail -f ~/log/rocketmqlogs/broker.log

启动Broker问题描述：RocketMQ默认的虚拟机内存较大，启动Broker如果因为内存不足失败，可以编辑如下两哥配置文件，修改JVM的内存大小

# 编辑runbroker.sh 和 runserver.sh 修改默认JVM大小
vim runbroker.sh
vim runserver.sh

runbroker.sh

runserver.sh

我们再次启动Broker

nohup sh ./mqbroker -n localhost:9876 &

查看日志可以看到已经启动成功

我们开两个控制台窗口，一个模拟生产者一个窗口模拟消费者

生产者：

## 生产者
1.设置环境变量
export NAMESRV_ADDR=localhost:9876
2.发送消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

消息发送运行效果图：

消费者：

## 消费者
1.设置环境变量
export NAMESRV_ADDR=localhost:9876
2.接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

消息接收运行效果图：

1.关闭Broker
sh bin/mqshutdown broker

2.关闭NameServer
sh bin/mqshutdown namesrv