• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

90%的Java程序员,最全SpringBoot学习教程

互联网 diligentman 3小时前 2次浏览

至于为什么叫做削峰填谷呢?来看看这个图:

90%的Java程序员,最全SpringBoot学习教程

如果没有用MQ的情况下,并发量高峰期的时候是有一个“顶峰”的,然后高峰期过后又是一个低并发的“谷”。

但是使用了MQ之后,限制消费消息的速度为1000,但是这样一来,高峰期产生的数据势必会被积压在MQ中,高峰就被“削”掉了。

但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在1000QPS,直到消费完积压的消息,这就叫做“填谷”

通过上面的分析,大家就可以知道为什么要使用MQ,以及使用了MQ有什么好处。知其所以然,明白了自己的系统为什么要使用MQ。

这样以后别人问你为啥要用MQ,就不会出现 “我们组长要用MQ我们就用了” 这样尴尬的回答了。

使用了MQ之后有什么优缺点?

看到这个问题蒙圈了,用了就用了嘛!优点上面已经说了,但是这个缺点是啥啊。好像没啥缺点啊。

如果你这样想,就大错特错了,在设计系统的过程中,除了要清楚的知道为什么要用这个东西,还要思考一下用了之后有什么坏处。这样才能心里有底,防范于未然。

接下来我们就讨论一下,用MQ会有什么缺点把?

系统可用性降低

大家想想一下,上面的说解耦的场景,本来A系统的哥们要把系统关键数据发送给BC系统的,现在突然加入了一个MQ了,现在BC系统接收数据要通过MQ来接收。

但是大家有没有考虑过一个问题,万一MQ挂了怎么办?这就引出一个问题,加入了MQ之后,系统的可用性是不是就降低了?

因为多了一个风险因素:MQ可能会挂掉。只要MQ挂了,数据没了,系统运行就不对了。

系统复杂度提高

本来我的系统通过接口调用一下就能完事的,但是加入一个MQ之后,需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题

为了解决这些问题,又需要引入很多复杂的机制,这样一来是不是系统的复杂度提高了。

数据一致性问题

本来好好的,A系统调用BC系统接口,如果BC系统出错了,会抛出异常,返回给A系统让A系统知道,这样的话就可以做回滚操作了

但是使用了MQ之后,A系统发送完消息就完事了,认为成功了。而刚好C系统写数据库的时候失败了,但是A认为C已经成功了?这样一来数据就不一致了。

通过分析引入MQ的优缺点之后,就明白了使用MQ有很多优点,但是会发现它带来的缺点又会需要你做各种额外的系统设计来弥补

最后你可能会发现整个系统复杂了好几倍,所以设计系统的时候要基于这些考虑做出取舍,很多时候你会发现该用的还是要用的。。。

怎么保证MQ消息不丢失?

使用了MQ之后,还要关心消息丢失的问题。这里我们挑RabbitMQ来说明一下吧。

生产者弄丢了数据

RabbitMQ生产者将数据发送到rabbitmq的时候,可能数据在网络传输中搞丢了,这个时候RabbitMQ收不到消息,消息就丢了。

RabbitMQ提供了两种方式来解决这个问题:

事务方式:

在生产者发送消息之前,通过channel.txSelect开启一个事务,接着发送消息

如果消息没有成功被RabbitMQ接收到,生产者会收到异常,此时就可以进行事务回滚channel.txRollback然后重新发送。假如RabbitMQ收到了这个消息,就可以提交事务channel.txCommit

但是这样一来,生产者的吞吐量和性能都会降低很多,现在一般不这么干。

另外一种方式就是通过confirm机制:

这个confirm模式是在生产者哪里设置的,就是每次写消息的时候会分配一个唯一的id,然后RabbitMQ收到之后会回传一个ack,告诉生产者这个消息ok了。

如果rabbitmq没有处理到这个消息,那么就回调一个nack的接口,这个时候生产者就可以重发。

事务机制和cnofirm机制最大的不同在于事务机制是同步的,提交一个事务之后会阻塞在那儿

但是confirm机制是异步的,发送一个消息之后就可以发送下一个消息,然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。

所以一般在生产者这块避免数据丢失,都是用confirm机制的。

Rabbitmq弄丢了数据

RabbitMQ集群也会弄丢消息,这个问题在官方文档的教程中也提到过,就是说在消息发送到RabbitMQ之后,默认是没有落地磁盘的,万一RabbitMQ宕机了,这个时候消息就丢失了。

所以为了解决这个问题,RabbitMQ提供了一个持久化的机制,消息写入之后会持久化到磁盘

这样哪怕是宕机了,恢复之后也会自动恢复之前存储的数据,这样的机制可以确保消息不会丢失。

设置持久化有两个步骤:

第一个是创建queue的时候将其设置为持久化的,这样就可以保证rabbitmq持久化queue的元数据,但是不会持久化queue里的数据

第二个是发送消息的时候将消息的deliveryMode设置为2,就是将消息设置为持久化的,此时rabbitmq就会将消息持久化到磁盘上去。

但是这样一来可能会有人说:万一消息发送到RabbitMQ之后,还没来得及持久化到磁盘就挂掉了,数据也丢失了,怎么办?

对于这个问题,其实是配合上面的confirm机制一起来保证的,就是在消息持久化到磁盘之后才会给生产者发送ack消息。

万一真的遇到了那种极端的情况,生产者是可以感知到的,此时生产者可以通过重试发送消息给别的RabbitMQ节点

消费端弄丢了数据

RabbitMQ消费端弄丢了数据的情况是这样的:在消费消息的时候,刚拿到消息,结果进程挂了,这个时候RabbitMQ就会认为你已经消费成功了,这条数据就丢了。

对于这个问题,要先说明一下RabbitMQ消费消息的机制:在消费者收到消息的时候,会发送一个ack给RabbitMQ,告诉RabbitMQ这条消息被消费到了,这样RabbitMQ就会把消息删除。

但是默认情况下这个发送ack的操作是自动提交的,也就是说消费者一收到这个消息就会自动返回ack给RabbitMQ,所以会出现丢消息的问题。

所以针对这个问题的解决方案就是:关闭RabbitMQ消费者的自动提交ack,在消费者处理完这条消息之后再手动提交ack。

这样即使遇到了上面的情况,RabbitMQ也不会把这条消息删除,会在你程序重启之后,重新下发这条消息过来。

怎么保证MQ的高可用性性?

使用了MQ之后,我们肯定是希望MQ有高可用特性,因为不可能接受机器宕机了,就无法收发消息的情况。

这一块我们也是基于RabbitMQ这种经典的MQ来说明一下:

RabbitMQ是比较有代表性的,因为是基于主从做高可用性的,我们就以他为例子讲解第一种MQ的高可用性怎么实现。

rabbitmq有三种模式:单机模式,普通集群模式,镜像集群模式

单机模式

单机模式就是demo级别的,就是说只有一台机器部署了一个RabbitMQ程序。

这个会存在单点问题,宕机就玩完了,没什么高可用性可言。一般就是你本地启动了玩玩儿的,没人生产用单机模式。

普通集群模式

这个模式的意思就是在多台机器上启动多个rabbitmq实例。类似的master-slave模式一样。

更多:Java进阶核心知识集

包含:JVM,JAVA集合,网络,JAVA多线程并发,JAVA基础,Spring原理,微服务,Zookeeper,Kafka,RabbitMQ,Hbase,MongoDB,Cassandra,设计模式,负载均衡,数据库,一致性哈希,JAVA算法,数据结构,加密算法,分布式缓存等等

90%的Java程序员,最全SpringBoot学习教程

**[CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】](

)

网盘:pan.baidu.com/s/1MtPP4d9Xy3qb7zrF4N8Qpg
提取码:2p8n

**

高效学习视频

ka,RabbitMQ,Hbase,MongoDB,Cassandra,设计模式,负载均衡,数据库,一致性哈希,JAVA算法,数据结构,加密算法,分布式缓存等等

[外链图片转存中…(img-AqrdQjQu-1631366949316)]

**[CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】](

)

网盘:pan.baidu.com/s/1MtPP4d9Xy3qb7zrF4N8Qpg
提取码:2p8n

**

高效学习视频


程序员灯塔
转载请注明原文链接:90%的Java程序员,最全SpringBoot学习教程
喜欢 (0)