|
|
@ -0,0 +1,72 @@
|
|
|
|
|
|
|
|
**<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>
|