消息总线Bus介绍及使用场景-消息队列和RabbitMQ介绍及安装

接上一章配置中心实战（十七），明显的缺点所在，虽然Config-server拉取配置，服务获取Config-server配置，但无法感知到配置的修改，也就是动态更新

什么是消息？

一个事件，需要广播或单独传递给某个接口

为什么使用这个？

配置更新了，但是其它系统不知道是否更新

消息队列

就是一个存放消息的容器，把要传输的数据放在队列里，实际应用场景有解耦、异步、削峰

应用解耦：比如A系统发送数据到BCD三个系统，通过接口发送，如果此时出现E系统也需要这个数据呢？如果C系统又不使用呢？在这种情况下系统耦合，A系统产生一条关键数据还要考虑BCDE四个系统如果挂掉了还要不要重发，要不要把消息存起来。
如果使用MQ，A系统产生一条数据，发送到MQ里面，那个系统需要数据去MQ里面消费，如果不需要就取消对MQ的消费即可。通过Pub/Sub发布订阅消息这么一个模型，A系统就可和其它系统彻底解耦，多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败

异步处理：比如A系统在自己本地运算，还需要再BCD三个系统调用，自己本地写要3ms，BCD分别写库时间加起来要1s，一般互联网企业，对于用户操作一般要求在200ms以内完成。
如果使用MQ，A系统连续发送3条消息到MQ队列中，假如耗时5ms，A系统从接收一个请求到返回响应用户总时长8ms
多应用对消息队列中同一消息进行处理，应用并发处理消息，相比串行处理，减少处理时间

削峰：每天0到12点，系统风平浪静，每秒并发请求数量就50个，结果一到12:00~13:00,每秒并发请求数量突然会暴增到5k+条，但是系统直接基于mysql，大量请求涌入mysql，一般mysql，扛到每秒2k条就差不多，直接请求5k的话，导致系统崩溃。
如果使用MQ，每秒5k请求写入MQ，系统每秒还是从MQ中拉取2k个请求，这样哪怕是高峰期，系统也不会挂掉，但每秒5k进，2k出导致在高峰期可能有十几万甚至几百万的请求积压在MQ中，短暂高峰期是OK的，高峰期一过依然处理积压请求。

官方文档

https://www.cnblogs.com/linjiqin/p/5720865.html

同类产品

ActiveMQ RocketMQ Kafaka等

SpringCloud默认推荐使用RibbitMQ

安装步骤 使用Docker搭建RabbitMQ

1）拉取镜像：docker pull rabbitmq:management

2）查看当前镜像列表：docker images

3）删除指定镜像：docker rmi IMAGE_ID (如果需要强制删除加 -f)

4）创建容器
docker run -d --name=“myrabbitmq” -p 5671:5671 -p 15672:15672 rabbitmq:management

参数讲解：
run：创建一个新的容器并运行一个命令
-d：后台运行容器，并返回容器ID
-p：端口映射，格式为：主机(宿主) 端口：容器端口
–name=“rabbitmq”：位容器指定一个名称

RabbitMQ默认创建了一个guest用户，密码也是guest，如果访问不了记得查看防火墙，端口或者云服务器的安全管理后台：http:/127.0.0.1:15672

可以参考博客讲解RibbitMQ控制台