
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
消息接收运行效果图:
关闭RocketMQ1.关闭Broker sh bin/mqshutdown broker 2.关闭NameServer sh bin/mqshutdown namesrv
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)