刚做的网站怎么在百度上能搜到,wordpress 后台实现轮播图,商城类网站价格,游戏制作编辑器什么是#xff2d;#xff31;消息队列及四大主流#xff2d;#xff31;的优缺点
小程序要上一个限时活动模块#xff0c;需要有延时队列#xff0c;从网上了解到用RabbitMQ可以解决#xff0c;就了解了下 MQ 并以此做记录。
一、为什么要用 MQ
核心就是解耦、异步和…什么是消息队列及四大主流的优缺点
小程序要上一个限时活动模块需要有延时队列从网上了解到用RabbitMQ可以解决就了解了下 MQ 并以此做记录。
一、为什么要用 MQ
核心就是解耦、异步和削峰。
1、系统解耦
下面这个场景现有ABCDE五个系统最初的时候BCD三个系统都要调用A系统的接口获取数据一切都很正常但是突然D系统说我不要了你不用给我传数据了A系统无奈只能修改代码将调用D系统的代码删除这时候还没删除呢E系统发送了请求但是A系统这时候还没处理完D系统的请求A系统卒彻底崩溃。 上述场景中BCDE都需要用到A系统提供的数据A系统跟其他四个系统严重耦合需要时时刻刻考虑其他四个系统要是挂了怎么办需不需要重新发送数据给他们这个时候的A系统内心是崩溃的。
总结通过MQ发布订阅消息的模型A系统就成功的跟其他系统解耦了。
2、异步调用
场景二还是ABCD四个系统A系统收到一个请求需要在自己本地写库还需要往BCD三个系统写库A系统自己写本地库需要3ms往其他系统写库相对较慢B系统200ms C系统350msD系统400ms这样算起来整个功能从请求到响应的时间为3ms200ms350ms400ms953ms接近一秒对于用户来说点个按钮要等这么长时间基本是无法接受的侧面也反映出这家研发人员技术不咋地。 一般的互联网企业对于用户请求响应的时间要求在100ms-200ms之间这样用户的眼睛存在视觉暂停现象用户响应时间在此范围内就可以了所以上面的现象是不可取的。
如果用了MQ用户发送请求到A系统耗时3msA系统发送三条消息到MQ假如耗时5ms用户从发送请求到相应3ms5ms8ms仅用了8ms用户的体验非常好。
3、流量削峰
2020年爆发的这场新冠病毒导致各大线上商城APP里面的口罩被抢购一空在这种情况下JD商城开启了一场每晚八点的抢购3Q口罩的活动每天下午三点进行预约晚上八点抢购从JD商城刚上线这个活动我连续抢了近一个周也算是见证了一个百万并发量系统从出现问题到完善的一个过程最初第一天我抢购的时候一百多万预约到八点抢购估计也能有百万的并发量可是第一天到八点我抢的时候由于并发量太高直接把JD服务器弄崩了直接报了异常可能JD在上线这个活动的时候也没能够想到会有那么高的并发打了一个猝不及防但是这只是在前一两天出现报异常的情况后面却没有再出现异常信息到后来再抢购只是响应的时间变得很慢但是JD系统并没有崩溃这种情况下一般就是用了MQ或者之前用了MQ这次换了个吞吐量级别更高的MQ也正是利用了MQ的三大好处之一——削峰。
JD系统每天0—19点系统风平浪静结果一到八点抢购的时候每秒并发达到百万假设JD数据库没秒能处理1.5w条并发请求并非实际数据主要为了举例,到八点抢购的时候每秒并发百万这直接导致系统异常但是八点一过可能也就几万用户在线操作每秒的请求可能也就几百条对整个系统毫无压力。
如果使用了MQ每秒百万个请求写入MQ因为JD系统每秒能处理1W的请求JD系统处理完然后再去MQ里面再拉取1W的请求处理每次不要超过自己能处理的最大请求量就ok这样下来等到八点高峰期的时候系统也不会挂掉但是近一个小时内系统处理请求的速度是肯定赶不上用户的并发请求的所以都会积压在MQ中甚至可能积压千万条但是高峰期过后每秒只会有一千多的并发请求进入MQ但是JD系统还是会以每秒1W的速度处理请求所以高峰期一过JD系统会很快消化掉积压在MQ的请求在用户那边可能也就是等的时间长一点但是绝对不会让系统挂掉。 二、消息队列优缺点
1、优点
上述已经说过在于解耦、异步和削峰。
2、缺点
①系统可用性降低 系统引入的外部依赖越多系统要面对的风险越高拿场景一来说本来ABCD四个系统配合的好好的没啥问题但是你偏要弄个MQ进来插一脚虽然好处挺多但是万一MQ挂掉了呢那样你系统不也就挂掉了。
②系统复杂程度提高 非要加个MQ进来如何保证没有重复消费呢如何处理消息丢失的情况怎么保证消息传递的顺序问题太多。
③一致性的问题 A系统处理完再传递给MQ就直接返回成功了用户以为你这个请求成功了但是如果在BCD的系统里BC两个系统写库成功D系统写库失败了怎么办这样就导致数据不一致了。所以。消息队列其实是一套非常复杂的架构你在享受MQ带来的好处的同时也要做各种技术方案把MQ带来的一系列的问题解决掉等一切都做好之后系统的复杂程度硬生生提高了一个等级。
三、四大主流MQkafka、ActiveMQ、RabbitMQ、RocketMQ各自的优缺点 四、总结
综上所述各种对比之后我个人倾向于是
不推荐用一般的业务系统要引入MQ最早大家都用ActiveMQ但是现在确实大家用的不多了没经过大规模吞吐量场景的验证社区也不是很活跃所以大家还是算了吧我个人不推荐用这个了
目前使用大部分公司后来大家开始用RabbitMQ但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他对公司而言几乎处于不可控的状态但是确实人是开源的比较稳定的支持活跃度也高
不过现在确实越来越多的公司会去用RocketMQ确实很不错但是我提醒一下自己想好社区万一突然黄掉的风险对自己公司技术实力有绝对自信的我推荐用RocketMQ否则回去老老实实用RabbitMQ吧人是活跃开源社区绝对不会黄
所以中小型公司技术实力较为一般技术挑战不是特别高用RabbitMQ是不错的选择大型公司基础架构研发实力较强用RocketMQ是很好的选择
如果是大数据领域的实时计算、日志采集等场景用Kafka是业内标准的绝对没问题社区活跃度很高绝对不会黄何况几乎是全世界这个领域的事实性规范。ok消息队列写到这里就结束了。
