我需要把网站做,网站后台无法修改,怎么做无损mp3下载网站,网站定制设计网页价格多少钱《面试之MQ篇》
1. 为什么要使用MQ
首先,面试官问的第一个问题或者说是逼问的一个问题#xff1a;“为什么要使用MQ”其实面试官问这个问题就是想考察你MQ的特性#xff0c;这个时候呢#xff0c;我们必须要答出三点#xff1a;解耦、异步、削峰。
1. 解耦
1. 传统系统…《面试之MQ篇》
1. 为什么要使用MQ
首先,面试官问的第一个问题或者说是逼问的一个问题“为什么要使用MQ”其实面试官问这个问题就是想考察你MQ的特性这个时候呢我们必须要答出三点解耦、异步、削峰。
1. 解耦
1. 传统系统耦合问题
在没有消息队列的系统中系统组件之间的通信往往是直接的、紧耦合的。例如在一个电商系统中订单系统和库存系统可能直接相互调用。当订单系统收到一个新订单时它会立即调用库存系统的接口来扣减库存。这种紧密耦合的方式使得系统难以维护和扩展。如果库存系统的接口发生变化比如增加了新的参数或者修改了接口的返回值那么订单系统也需要相应地修改代码来适应这种变化。而且当库存系统出现故障时订单系统的订单处理功能可能也会受到影响因为它依赖于库存系统的正常运行。
2. 消息队列解耦的优势
使用消息队列后订单系统和库存系统之间通过消息进行通信。订单系统将订单信息作为消息发送到消息队列中库存系统从消息队列中获取订单消息并进行库存扣减。这样订单系统和库存系统就不再直接相互依赖。库存系统的接口变化不会直接影响订单系统只要消息的格式和内容保持一致订单系统就可以继续正常工作。同时即使库存系统出现故障订单消息可以在消息队列中暂存等库存系统恢复后再进行处理不会导致订单系统的功能受阻。
2. 异步
1. 同步处理的局限性
以用户注册场景为例在一个简单的系统设计中如果没有消息队列用户提交注册信息后系统可能需要依次完成多项任务如验证用户信息、创建用户数据库记录、发送注册邮件等。这些任务都是同步执行的用户需要等待所有任务完成后才能得到注册成功的反馈。假设验证用户信息需要 1 秒创建用户记录需要 2 秒发送注册邮件需要 3 秒那么用户总共需要等待 6 秒才能得到注册成功的反馈。这种长时间的等待会导致用户体验不佳尤其是在高并发的情况下系统的响应时间会变得很长。
2. 消息队列异步处理的优势
使用消息队列后用户提交注册信息后系统可以将注册信息作为消息发送到消息队列中然后立即返回注册成功的反馈给用户。后台的服务可以从消息队列中获取注册消息分别异步地进行验证用户信息、创建用户记录和发送注册邮件等任务。这样从用户的角度来看响应时间大大缩短可能只需要几毫秒就能得到注册成功的反馈。同时系统的整体性能也得到了提升因为这些任务可以在后台并行地进行处理而不是依次等待完成。
3. 削峰
1. 流量高峰的挑战
在一些高并发的场景中如电商的秒杀活动或者热门景点的门票预订系统可能会在短时间内接收到大量的请求。如果没有消息队列这些请求会直接冲击后端的服务如数据库、应用服务器等。以秒杀活动为例假设数据库每秒只能处理 1000 个订单插入操作但秒杀活动开始时每秒有 10000 个订单请求。如果所有请求直接发送到数据库数据库很可能会因为不堪重负而出现性能下降、甚至崩溃的情况。
2. 消息队列削峰的原理和优势
使用消息队列后这些大量的请求可以先发送到消息队列中进行缓冲。消息队列可以承受高并发的消息流入将请求暂时存储起来。后端的服务可以按照自己的处理能力从消息队列中获取消息进行处理。例如数据库每秒能处理 1000 个订单那么它就可以以这个速度从消息队列中获取订单消息进行处理。这样通过消息队列的缓冲作用有效地避免了后端服务被瞬间的高流量冲垮保证了系统的稳定性和可靠性。
1.1. 总结话术
面试官您好使用消息队列MQ主要有三个重要原因。 首先呢就是mq具有解耦的特性在复杂的软件系统中不同的模块之间往往存在着紧密的依赖关系。如果不使用 MQ模块之间可能会直接进行方法调用这会导致高度耦合。例如在一个电商系统中订单模块和库存模块、物流模块等可能直接交互。一旦其中一个模块的接口发生变化就会影响到与之直接交互的其他模块使得系统的维护变得极为困难。 而引入 MQ 后各个模块之间通过发送和接收消息进行通信不再直接依赖对方的接口。订单模块在生成订单后将订单消息发送到 MQ库存模块和物流模块从 MQ 中获取订单消息并进行相应的处理。这样即使某个模块出现故障也不会直接影响到其他模块的正常运行极大地提高了系统的可维护性和可扩展性。 再一个呢就是因为它能异步处理消息了 在没有 MQ 的情况下很多业务流程往往是同步执行的。比如在一个在线教育平台中学生提交作业后系统需要进行作业存储、批改、反馈等一系列操作。如果这些操作都是同步进行的学生就需要等待所有操作完成后才能得到反馈这会导致响应时间过长影响用户体验。 使用 MQ 后可以将这些操作异步化。学生提交作业后系统将作业提交的消息发送到 MQ然后立即返回提交成功的响应。后台的作业存储、批改、反馈等服务可以从 MQ 中获取作业消息并进行异步处理。这样学生能够快速得到反馈同时系统也能够更加高效地利用资源提高整体性能。 最后一点就是因为它具有流量削峰的特性 在一些特定场景下系统可能会面临瞬间的高流量冲击。比如电商平台的促销活动、抢购活动等短时间内会有大量的用户请求涌入。如果没有 MQ这些请求会直接到达后端服务可能会导致服务过载甚至崩溃。 通过 MQ可以将这些突发的高流量请求缓冲起来。用户的请求先发送到 MQ后端服务按照自己的处理能力从 MQ 中获取请求进行处理。这样就能够有效地避免系统因瞬间高流量而崩溃保证系统在高负载情况下的稳定性。 我的回答完毕谢谢
2. 消息队列有什么优点和缺点
1. 优点
一解耦系统
传统系统耦合问题说明
在传统的紧耦合系统中系统的各个模块之间直接相互调用。例如在一个电商系统里订单系统和库存系统紧密相连。当订单系统接收到一个新订单时它会马上调用库存系统的接口来更新库存。这种方式使得两个系统高度依赖彼此的接口细节。如果库存系统的接口发生变化比如增加了一个新的参数用于记录库存更新的原因那么订单系统就需要相应地修改代码来适应这个新参数。而且当库存系统出现故障订单系统可能会因为无法成功调用库存更新接口而无法正常处理订单。
消息队列解耦原理及优势
消息队列的引入改变了这种紧密耦合的状态。以刚才的电商系统为例订单系统将新订单信息作为消息发送到消息队列中库存系统从消息队列中获取消息来更新库存。这样一来订单系统和库存系统之间不再直接依赖对方的接口。库存系统的接口变化只要不影响消息的格式和内容就不会对订单系统产生影响。即使库存系统出现故障订单消息可以在消息队列中暂存等到库存系统恢复后再进行处理从而提高了系统的可维护性和灵活性。
二异步处理
同步处理的局限案例分析
考虑一个用户注册的场景。在没有消息队列的系统中用户提交注册信息后系统需要依次完成验证用户信息假设耗时 1 秒、创建用户数据库记录假设耗时 2 秒、发送注册欢迎邮件假设耗时 3 秒等操作。这些操作是同步执行的用户需要等待所有操作完成后才能得到注册成功的反馈总共需要等待 1 2 3 6 秒这在用户体验上是比较差的尤其是在高并发的情况下系统的响应时间会因为这种同步等待而变得很长。
消息队列异步处理优势阐述
当使用消息队列时用户提交注册信息后系统将注册信息作为消息发送到消息队列中然后立即返回注册成功的反馈给用户。后台的服务可以从消息队列中获取注册消息分别异步地进行验证用户信息、创建用户记录和发送注册欢迎邮件等操作。这样从用户角度来看响应时间可能缩短到几毫秒大大提升了用户体验。同时系统的整体性能也得到提高因为这些任务可以在后台并行地进行处理提高了资源的利用效率。
三流量削峰
流量高峰的危害示例
在电商的秒杀活动中瞬间可能会有成千上万的用户请求涌入。如果没有消息队列这些请求会直接冲击后端的服务比如数据库。假设数据库每秒能够稳定处理 1000 笔订单插入操作但在秒杀活动开始的瞬间每秒有 10000 笔订单请求。如果所有请求直接发送到数据库数据库很可能会因为不堪重负而出现性能下降如查询和插入操作变得极其缓慢甚至可能会因为资源耗尽而崩溃。
消息队列削峰机制及优势
消息队列可以将这些大量的请求先缓冲起来。在秒杀场景中用户的订单请求先发送到消息队列。后端的数据库服务可以按照自己的处理能力比如每秒处理 1000 笔订单的速度从消息队列中获取订单消息进行处理。这样就有效地避免了后端服务被瞬间的高流量冲垮使得系统在高负载情况下依然能够保持相对稳定的运行状态保证了系统的可靠性。
四广播和多播能力
广播功能说明及应用场景
消息队列可以将一条消息广播给多个消费者。例如在一个新闻发布系统中当有重要新闻发布时消息队列可以将新闻消息广播给所有订阅了新闻频道的客户端应用。这些客户端应用可以是网页端、移动端等不同平台的应用它们都能从消息队列中获取到相同的新闻消息从而实现了消息的广泛传播。
多播功能介绍及适用场景
多播功能则允许消息被发送到一组特定的消费者。以一个企业内部的系统为例当有一个部门级别的通知需要发送时消息队列可以将通知消息发送给该部门对应的一组消费者如该部门的员工使用的工作软件客户端。这种广播和多播能力提高了消息传递的效率使得消息能够快速地到达多个目标接收者适合于需要一对多或组播消息传递的场景。
五可扩展性
水平扩展的便利性
消息队列系统本身通常很容易进行水平扩展。随着业务的增长系统的消息处理量不断增加可以通过添加更多的消息队列服务器或者消息代理如在RocketMQ 中的 Broker来处理更多的消息。例如当一个电商平台的订单消息量从每天 10 万条增长到每天 100 万条时可以增加消息队列服务器的数量来应对这种增长。新添加的服务器可以分担原有的消息处理任务并且在配置好相关的路由和负载均衡后整个系统可以平稳地运行不需要对现有系统的架构进行大规模的修改。
对业务扩展的支持
对于业务系统来说消息队列的可扩展性也提供了很大的便利。以一个物流系统为例随着业务的拓展需要增加新的物流服务提供商或者新的物流信息处理模块。只要这些新的模块遵循消息队列的消息格式和通信协议就可以很容易地接入到现有的消息队列系统中。它们可以从消息队列中获取自己需要的消息如订单发货消息或者货物运输状态消息从而实现了业务系统的平滑扩展。
2. 缺点
一系统复杂性增加
架构复杂性
引入消息队列后系统架构变得更加复杂。除了原有的业务系统模块还需要引入消息队列服务器、消息生产者和消费者等组件。例如在一个简单的三层架构表示层、业务逻辑层、数据访问层的应用中加入消息队列后需要考虑如何在业务逻辑层正确地生产消息以及在其他可能的模块中作为消费者接收和处理消息。这需要设计新的通信路径和处理逻辑增加了系统架构设计的难度。
运维复杂性
消息队列的运维也比较复杂。需要监控消息队列服务器的性能指标如消息堆积情况、服务器的负载、网络带宽的使用等。当出现问题时如消息丢失、消息重复消费等需要有相应的技术手段来解决。例如要确定消息丢失是在生产阶段、传输阶段还是消费阶段并且采取不同的措施来恢复丢失的消息这对运维人员的技术要求较高。
二一致性问题
最终一致性挑战
在分布式系统中使用消息队列可能会导致数据一致性的问题。例如一个事务涉及多个系统其中一个系统通过消息队列发送消息来触发其他系统的操作。由于消息队列的异步特性可能会出现消息还未被其他系统处理而发起事务的系统已经完成了自己部分的操作并提交。这就导致了系统之间的数据在一段时间内可能不一致需要通过一些额外的机制来保证最终一致性。
分布式事务处理困难
处理分布式事务与消息队列结合的情况比较复杂。比如在一个包含消息队列的电商系统中订单系统和库存系统通过消息队列通信来处理订单和库存事务。如果订单系统成功发送了订单消息但库存系统在消费消息时出现故障就需要有复杂的机制来处理这种情况如事务补偿机制、消息重试等以确保订单和库存操作最终能够正确完成保证系统的一致性。
三消息可靠性问题
消息丢失风险
消息在生产、传输和消费过程中都有可能丢失。在生产阶段如果生产者没有正确地将消息发送到消息队列或者消息队列服务器出现故障导致消息未被正确接收就会发生消息丢失。例如在网络不稳定的情况下生产者发送消息时可能因为网络中断而无法成功将消息发送到消息队列。在传输过程中如果消息队列服务器之间的网络出现故障或者存储出现问题也可能导致消息丢失。
消息重复消费风险
消息可能会被重复消费。例如消费者在处理消息后由于网络抖动或者系统故障等原因没有正确地向消息队列确认消息已经被消费消息队列可能会认为该消息没有被消费从而将消息再次发送给消费者。这就需要消费者具备幂等性即对同一操作的多次重复执行结果和单次执行结果相同来避免重复消费带来的问题增加了系统开发的复杂性。
3. RabbitMQ死信队列、延时队列分别是什么
1. 死信队列
DLXDead Letter Exchange死信交换器。 当队列中的消息被拒绝、或者过期会变成死信死信可以被重新发布到另一个交换器这个交换器就是DLX与DLX绑定的队列称为死信队列。 造成死信的原因
信息被拒绝信息超时超过了队列的最大长度
2. 延迟队列
延迟队列存储的是延迟消息
延迟消息指的是当消息被发发布出去之后并不立即投递给消费者而是在指定时间之后投递。如 在订单系统中订单有30秒的付款时间在订单超时之后在投递给消费者处理超时订单。
rabbitMq没有直接支持延迟队列可以通过死信队列实现。在死信队列中可以为普通交换器绑定多个消息队列假设绑定过期时间为5分钟10分钟和30分钟3个消息队列然后为每个消息队列设置DLX为每个DLX关联一个死信队列。当消息过期之后被转存到对应的死信队列中然后投递给指定的消费者消费。
