72 lines
6.0 KiB
Markdown
72 lines
6.0 KiB
Markdown
|
**<h2>使用MQ的场景和优点</h2>**
|
|||
|
|
#### 解耦
|
|||
|
|
看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......<br>
|
|||
|
|
<br>
|
|||
|
|
在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！<br>
|
|||
|
|
如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。<br>
|
|||
|
|
<br>
|
|||
|
|
**总结**：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。<br>
|
|||
|
|
|
|||
|
|
#### 异步
|
|||
|
|
再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。<br>
|
|||
|
|
<br>
|
|||
|
|
一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。<br>
|
|||
|
|
如果**使用 MQ**，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！<br>
|
|||
|
|
<br>
|
|||
|
|
|
|||
|
|
#### 削峰
|
|||
|
|
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。<br>
|
|||
|
|
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。<br>
|
|||
|
|
但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。<br>
|
|||
|
|
<br>
|
|||
|
|
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。<br>
|
|||
|
|
<br>
|
|||
|
|
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。<br>
|
|||
|
|
|
|||
|
|
**<h2>RabbitMQ简介</h2>**
|
|||
|
|
RabbitMQ是一个开源的消息代理的队列服务器，用来通过普通协议在完全不同的应用之间共享数据。<br>
|
|||
|
|
RabbitMQ是使用Erlang语言来编写的，并且RabbitMQ是基于AMQP协议的。<br>
|
|||
|
|
Erlang语言在数据交互方面性能优秀，有着和原生Socket一样的延迟，<br>
|
|||
|
|
这也是RabbitMQ高性能的原因所在。可谓“人如其名”，RabbitMQ像兔子一样迅速。<br>
|
|||
|
|
|
|||
|
|
**<h2>RabbitMQ安装</h2>**
|
|||
|
|
**<h3>RabbitMQ官方下载</h3>**
|
|||
|
|
https://www.rabbitmq.com/download.html
|
|||
|
|
**<h3>Docker下载</h3>**
|
|||
|
|
docker run -d --hostname hostname \
|
|||
|
|
--name name \
|
|||
|
|
-p 15672:15672 \
|
|||
|
|
-p 5672:5672 \
|
|||
|
|
-e "RABBITMQ_DEFAULT_USER=username" \
|
|||
|
|
-e "RABBITMQ_DEFAULT_PASS=password" \
|
|||
|
|
rabbitmq
|
|||
|
|
|
|||
|
|
**<h2>RabbitMQ常用交换机</h2>**
|
|||
|
|
**<h3>直连型交换机-Direct Exchange</h3>**
|
|||
|
|
一一对应的模式，本次提交的代码即为该模式，用于日志组件的调用
|
|||
|
|
**<h3>主题交换机-Topic Exchange</h3>**
|
|||
|
|
根据规则一对多的模式，比较负责的项目会使用到
|
|||
|
|
**<h3>扇型交换机-Fanout Exchange</h3>**
|
|||
|
|
广播的模式，不太注重幂等性的场景可能会使用到
|
|||
|
|
|
|||
|
|
**<h2>Nacos中配置yml</h2>**
|
|||
|
|
\# spring配置<br>
|
|||
|
|
spring: <br>
|
|||
|
|
\# 配置rabbitMq 服务器<br>
|
|||
|
|
 rabbitmq:<br>
|
|||
|
|
  host: ip<br>
|
|||
|
|
  port: port<br>
|
|||
|
|
  username: username<br>
|
|||
|
|
  password: password<br>
|
|||
|
|
  \# 确认消息已发送到交换机(Exchange)<br>
|
|||
|
|
  publisher-confirm-type: correlated<br>
|
|||
|
|
  \# 确认消息已发送到队列(Queue)<br>
|
|||
|
|
  publisher-returns: true<br>
|
|||
|
|
  listener:<br>
|
|||
|
|
   simple:<br>
|
|||
|
|
    acknowledge-mode: manual<br>
|
|||
|
|
|
|||
|
|
**<h2>操作日志切换为MQ模式</h2>**<br>
|
|||
|
|
<h3>step1：将AsyncLogService的@Primary注解删除<br></h3>
|
|||
|
|
<h3>step2：给RabbitLogService添加@Primary注解<br></h3>
|
|||
|
|
<h3>step3：启动项目即可</h3>
|