chanong 贵公司有什么业务场景？ 这个业务场景有哪些技术挑战？ 如果你不使用MQ，可能会很麻烦，但是现在使用MQ，它给你带来了很多好处。
核心有三个：解耦、异步、削峰。
解耦
总结：通过MQ和Pub/Sub发布订阅消息的模型，系统A与其他系统完全解耦。
面试技巧：你需要考虑你所负责的系统中是否存在类似的场景，即一个系统或一个模块调用多个系统或模块。 相互之间的调用非常复杂，维护起来也很麻烦。 但实际上，这个调用并不需要直接同步调用接口。 如果用MQ来异步解耦也是可以的。 你需要考虑是否可以在你的项目中使用这个MQ来解耦系统。 。 在简历中体现这个东西，用MQ进行解耦。
异步
让我们看看另一个场景。 系统A收到请求，需要在本地写入库。 还需要在三个BCD系统中编写库。 本地写库耗时3ms，三个BCD系统写库分别耗时300ms、450ms、200ms。 最终总请求延迟为3 + 300 + 450 + 200 = 953ms，接近1s。 用户感觉正在做某事，但速度极其缓慢。 用户通过浏览器发起请求，等待1秒，这几乎是无法接受的。
对于一般的互联网公司来说，用户直接操作的一般要求是每个请求必须在200ms内完成，这对于用户来说几乎是无法察觉的。
如果使用MQ，那么系统A会连续向MQ队列发送3条消息。 如果需要5ms，则系统A从接受请求到向用户返回响应的总时间为3 + 5 = 8ms。 对于用户来说，其实感觉就像是点击一个按钮，8ms后直接返回。 这很棒！ 该网站做得很好，速度也很快！
削峰
一般来说，MySQL每秒可以处理2k个请求。 如果每秒的请求数达到5k，MySQL可能会被直接杀死，导致系统崩溃，用户将无法再使用系统。
如果使用MQ，每秒有5k个请求写入MQ，系统A每秒最多可以处理2k个请求，因为MySQL每秒最多可以处理2k个请求。 系统A缓慢地从MQ拉取请求，每秒拉取2k个请求。 如果不超过每秒可以处理的最大请求数就可以了。 这样，即使在高峰期，系统A也永远不会挂掉。 MQ 每秒接收 5k 个请求，只有 2k 个请求发出。 因此，在中午高峰期（1小时），MQ中可能会积压数十万甚至数百万的请求。
这段短暂的高峰期积压还可以，因为高峰期过后，每秒有50个请求进入MQ，但系统A每秒仍会处理2k个请求。 因此，一旦高峰期结束，系统A就会快速清理积压的消息。
2、消息队列的优点和缺点是什么？
其缺点如下：
系统引入的外部依赖越多，就越容易失败。 本来只要系统A调用BCD三个系统的接口即可。 四个系统ABCD都还好，没有问题。 如果添加了MQ，如果MQ挂了怎么办？ 一旦MQ挂了，整个系统崩溃了，那不是就完蛋了吗？ 如何保证消息队列的高可用。
如果突然添加MQ，如何保证消息不被重复消费？ 消息丢失如何处理？ 如何保证消息传递的顺序？ 我的头很大，有很多问题，也有很多痛苦。
系统A处理后直接返回成功。 人们认为你的请求成功了。 但问题是，如果有三个系统BCD和两个系统BD写库成功，但是系统C写库失败，怎么办？ 你的数据不一致。
所以消息队列实际上是一个非常复杂的架构。 引入它有很多好处，但你也必须做出各种额外的技术方案和架构来避免它带来的缺点。 做好了之后你会发现……是啊，系统复杂度增加了一个数量级，可能复杂了10倍。 但关键时刻，还是得用。
3.Kafka有哪些优缺点？特点
单机吞吐量
万级，比Kafka低一个数量级
相同的
10万级，支持高吞吐量
10万级，高吞吐量，一般与大数据系统配合使用，用于实时数据计算、日志采集等场景
主题数量对吞吐量的影响
主题可以达到数百/千的级别，吞吐量会略有下降。 这是一个主要优点。 同一台机器可以支持大量的主题。
当主题数量从几十个增加到几百个时，吞吐量会明显下降。 在同一台机器上，Kafka尽量保证主题数量不要太多。 如果要支持大规模的主题，就需要增加更多的机器资源。
时效性
女士级别
微秒级，这是一大特点，延迟最低
女士级别
延迟在ms级以内
可用性
高，基于主从架构实现高可用
相同的
非常高，分布式架构
非常高，分布式，一份数据有多个副本。 如果有几台机器出现故障，也不会出现数据丢失或不可用的情况。
消息可靠性
丢失数据的概率较低
基本不会丢失
经过参数优化和配置，可以实现0损失
相同的
功能支持
MQ域的功能极其齐全
基于开发，具有强大的并发能力、优异的性能、低延迟。
MQ功能比较齐全，是分布式的，具有良好的扩展性。
功能比较简单，主要支持简单的MQ功能，大规模用于大数据领域的实时计算和日志采集。
综上，经过多方比较，我们有以下建议：
一般业务系统都需要引入MQ。 起初大家都用过，但现在确实用得不多了。 尚未在大规模吞吐量场景中得到验证，社区也不是很活跃，所以大家还是忘记吧。 我个人不推荐它。 用这个;
后来大家都开始使用它，但是该语言确实阻碍了大量Java工程师深入研究和驾驭它。 对于公司来说，几乎是不可控的，但确实是开源的，有比较稳定的支持，活跃度很高；
但现在确实越来越多的企业在使用它，这确实很好。 毕竟是阿里巴巴出品，但可能存在社区突然过时的风险（目前已经捐赠了，但网站活跃度其实不是很高）。 如果您对自己的技术实力绝对有信心，建议使用。 否则，回到诚实和务实的态度。 有活跃的开源社区，你绝对不会色情。
因此，对于中小企业来说，技术实力比较一般，技术挑战不是特别高，使用它是一个不错的选择； 对于大公司来说，基础设施研发能力较强，使用它是一个不错的选择。
如果是大数据领域的实时计算、日志采集等场景，使用Kafka是行业标准，绝对没有问题。 社区非常活跃，绝对不会色情，更何况它几乎是全世界这个领域的事实上的标准。
4、如何保证消息队列的高可用？
根据所使用的消息中间件具体回答。
5、如何保证消息不被重复消费？ 也就是说，如何保证消息消费的幂等性？
根据所使用的消息中间件具体回答。
6、如何保证消息的可靠传输？ 也就是说，如何处理消息丢失的问题呢？
生产者、MQ、消费者都可能出现数据丢失问题。 具体答案取决于所使用的消息中间件。
7. 如何保证消息的顺序？
根据所使用的消息中间件具体回答。
8、大量消息在mq中积压了几个小时还没有解决。
一个消费者每秒有 1,000 条消息，三个消费者每秒有 3,000 条消息，每分钟有 180,000 条消息。 所以如果你积压了几百万到几千万的数据，即使消费者恢复了，也需要一个小时左右才能恢复。
一般这个时候只能做临时应急扩容。 具体操作步骤和思路如下：
9、mq中的消息已过期失效。
假设您使用的是 ，您可以设置过期时间，即 TTL。 如果消息在队列中积压超过一定时间，就会被清除，数据就会丢失。 那么这就是第二个陷阱。 这并不是说mq中会积累大量的数据，而是大量的数据会直接丢失。
对于这种情况，我们可以采用一个解决方案，就是批量重定向，写一个程序，针对丢失的这批数据写一个临时程序，逐位检查出来，然后重新填充到mq中，将丢失的数据去掉。那天。 把数据还给他。 只能这样了。
假设mq中有10000个订单积压未处理，其中1000个订单丢失。 只能手动写个程序把那1000个订单查出来，然后手动发送到mq再补。
10.mq 快满了
如果消息积压在mq中，并且你很长时间没有处理它们，那么mq就快满了。 你该怎么办？ 还有其他方法可以做到这一点吗？ 不对，谁告诉你你的第一个计划执行得太慢了？ 你编写了一个临时程序，访问数据进行消费，消费了一个并丢弃了另一个，然后快速消费了所有消息。 然后采取第二种方案，晚上补充数据。
11、写消息队列时架构如何设计？
例如，我们从以下几个角度来考虑这个消息队列系统：
微信扫一扫打赏
支付宝扫一扫打赏
