网站开发项目总结,营销型企业网站建站,企业网站建设比较好,正规的建网站公司#x1f4dd;个人主页#xff1a;五敷有你 #x1f525;系列专栏#xff1a;MQ
⛺️稳中求进#xff0c;晒太阳 定义 消息队列#xff1a;一般我们简称为MQ(Message Queue) Message Queue :消息队列中间件#xff0c;很多初学者认为#xff0c;MQ通过消息的发送… 个人主页五敷有你 系列专栏MQ
⛺️稳中求进晒太阳 定义 消息队列一般我们简称为MQ(Message Queue) Message Queue :消息队列中间件很多初学者认为MQ通过消息的发送和接受来实现程序的异步和解耦。mq主要用于异步操作这个并不是mq的真正目的这只是mq的应用mq的真正目的是为了通讯。 使用场景
消息队列的三个最主要的作用异步、消峰、解耦。
传统设计 这种设计模式有一个很大的优势代码简单出现问题容易定位。但是也有劣势。
从三高(高并发高性能高可用)三个方面去评审这个设计
高可用这些服务假如挂掉宕机或网络波动就意味着请求失败用户体验感极差。高并发因为这些操作都是由一个线程主线程去执行这些操作所以当我们的QPS如果很高的话很容易造成超时。QPS系统每秒钟收到的请求。高性能因为上面这种设计模式是串行的假设我的每次网络传输耗时200ms业务处理需要20ms完成上面那些操作需要耗时2s这样用户体验也会很差想象一下每次下单都需要等2s,如果用户下单后的操作越来越多耗时只会越来越高
所以在一个大型的互联网项目中以上设计是完全不可取的非核心模块除外。
并行处理调优
既然上面说的是串行模块那么我们用自己的线程池把他改为并行的设计再看评审一下。
所谓的并行设计就是原来由一个线程去串行做的逻辑改为多个线程并行去做。 高可用这些服务假如有一个服务挂掉宕机或者网络波动理论上讲如果补偿服务做的出色的话还是满足高可用的。可以用try,catch
高并发相比上面的设计系统的吞吐量可以达到了很大程度上的提升。
高性能相比上面的设计因为很多业务是并行执行的所以相当于只有200*220就可以返回。
上面这个设计看起来还是不错的设计所以在很多这种串行调用多次io的时候我们就可以采用这种方案上面这种设计也是多线程的一种实战应用。
下面来分析一下弊端
1.系统的可扩展性太差了。上面只是列举了4步但是实际上会有几十步这几十步放到代码里就会像屎堆一样可维护性极差。每次加一个步骤都要多调一个接口然后重新发布一下服务。
2系统的耦合性太高了。想象一下几十个http调用放到一起并发执行很有可能会影响其他的点尤其是淘宝京东这种秒杀敏感的业务和钱挂钩的业务很容易出现p0级别的bug。
3使用的业务本身的线程池在并发很多的情况下容易造成cpu的竞争。
于是就有了进一步演化。
多线程处理三种方案
1主线程交给线程池里的线程去执行时主线程等待等我所有任务执行完之后主线程再去接着执行查询做聚合的时候
2主线程交给线程池去处理就不管了我要删除或修改一个东西需要耗时2s
3主线程交给线程池去处理主线程继续去执行其他的任务等线程池里的任务执行完之后去通知主线程主线程在接着去执行后续的逻辑。 消息队列 咱们从继续从三高的层面去审视一下这个设计
高可用当我系统里的一个模块宕机了不会影响到我其他服务。可以通过数据补偿或者分布式事务来保证数据最终一致性
高性能用户下单将下单所需要的数据都放到消息队列里就直接返回了所有耗时相当于就是网络传输所耗时。
高并发由于消息队列不处理任何业务上的逻辑所有他支持的并发是百万级别的。假如有100万个用户下单100万的数据放到消息队列里连接消息队列的服务慢慢消费即可也不至于造成瞬间有百万请求进来将我的服务压垮。 消息队列的一些术语 producer 消息生产发布者 consumer 消息消费订阅者
三大优点
解耦就像高可用里面说的一样发淘金币服务挂了关下单什么关系发淘金币服务挂了我还是可以正常下单只不过后期可以数据补偿或者分布式事务去解决这个问题。
削峰比如说我平时服务就只能支撑几万的qps像淘宝京东那种秒杀那时候服务突然打进来如果采用第二种方案那服务就会直接被压死了。但是如果采用消息队列这秒杀进来的所有的请求都不会直接打到具体服务上都会先打到消息队列里然后我后面的服务再慢慢消费。
可以看看淘宝京东双11秒杀的时候是不是有的时候慢是慢了点但是服务起码没挂。等我秒杀结束之后服务还能正常运转。
消息队列就像是一个三峡大坝用来拦截上游给的压力。
异步连接消息队列的服务可以异步去执行。而且每次多增加一个步骤我下单的代码是不需要动的只需要再增加一个消费者即可。
消息队列也并不是全是优点也有一些缺点。
缺点
1增加了系统复杂性。
所以说如果说你的业务量不大并发也不高就没必要使用消息队列。
2事务问题。
事务问题其实是分布式系统肯定会存在的一个问题只不过消息队列更严重一些。一般解决方案有两种第一种就是采用分布式事务这个下单的里涉及的所有服务放到一个事务里面要么都成功要么都失败。第二种就是消费者做好合理的数据补偿措施比如说消息重试人工刷数据等等。
3可用性
刚才讲了解耦其实是系统的各个模块之间的解耦但是这些模块都和消息队列关联万一消息队列挂了就真的下不了单了。为了保证可用性我们可以采用消息队列集群前端流量限流等后面会介绍。
几种常见的消息队列 其中kafka和rocketmq现在在互联网大厂使用最广泛因为吞吐量大。
MQ的两种流派
1、有broker的
broker是什么可以理解为是一个中转站。生产者将消息发送给他就结束自己的任务了broker将消息主动推送给消费者具体的将消息推送到哪个队列或者说消费者主动请求
重topic
必须要有topic
kafka全球消息处理性能最快的一款mq
rocketmq阿里内部的一个大神根据kafka的执行原理手写的性能与kafka差不多但是功能上比kafka要多比如说顺序消费。
轻topic
可以没有topictopic只是一种中转模式
rabbitmq
2、无broker的
zeromq没有使用broker是直接使用socket进行通信。
