每天十道面试题-20200409

题目

• 1、为什么必须要在系统里引入消息中间件?
• 2、消息中间件技术选型为什么选择这个中间件？
• 3、为什么不用其他的呢?技术选型的依据是什么?
• 4、如何保证消息中间件的高可用性?
• 5、如何避免消息中间件故障后引发系统整体故障?
• 6、如何保证投递出去的消息一定不会丢失?
• 7、如何保证投递出去的消息只有一条且仅仅一条，不会出现重复的数据?
• 8、重复消费的消息怎么保证数据的准确性?
• 9、是否需要保证消息的顺序性?需要为什么需要如何保证？不需要为什么不需要？
• 10、消费系统宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?

解答

题目一

• 题干：为什么必须要在系统里引入消息中间件?
• 分析：

• 系统引入消息中间件主要围绕着 异步、削峰、解耦这6个字展开，如果没有没有消息中间件，那么我们会遇到什么问题呢？
  1、系统之间耦合度过高
  如果我们有一个给其他系统提供数据的核心系统A，目前有B、C、D系统依赖于A系统的核心数据，并且随着业务发展还会有E、F、G系统需要使用到A系统的数据，这就会导致除A系统外的多个系统强依赖于A系统，并且我们需要将获取A系统数据的代码在多个系统间复用。
  2、同步等待时间过长且非必要
  如果A系统调用B系统需要1秒B系统调用C系统需要一秒这时整个调用链路A-B-C 共需约2秒，如果此时引入系统D 然后C系统调用D如果调用耗时需要2秒，那么现在A-B-C-D总体约耗时至少4秒耗时翻倍，此时同步等待带来问题，如果C-D的调用不一定需要同步，那这个调用给性能带来的损耗是没必要的。
  3、在一些秒杀或者抢购场景下，QPS会很高如果没有缓存层，所有的请求直接打到数据库将会导致数据库崩溃。那么我们如何能抗住短时的高并发，并且让我们的所有产品卖出去呢？
  消息中间件就可以解决上面的问题。
  对于问题1 A中的系统将数据发送到消息中间件，然后所有需要该数据的系统订阅相关topic代码重复率低且解耦合，当然我们需要保证消息中间件的HA。问题2所有的请求丢到消息中间件，系统处理后可以将处理结果也放到消息中间件然后其他系统订阅。问题3，所有订单请求全部堆到消息中间件，然后逐步处理。

• 回答：

• 异步、削峰、解耦。

题目二

• 题干：消息中间件技术选型为什么选择这个中间件？
• 分析：

• 主要是考虑，团队成员对该中间件的掌握以及维护这个是最基本的，然后业务场景，对并发的要求，对消息顺序性的要求，对消息重试的要求，对消息回溯的要求等等 传送门 这篇文章从多个维度列举了当下常用的消息中间件的特性。

• 回答：

• 见分析。

题目三

• 题干：为什么不用其他的呢?技术选型的依据是什么?
• 分析：

• 参考题目二。

• 回答：

• 参考题目二。

题目四

• 题干：如何保证消息中间件的高可用性?
• 分析：

• 对于RocketMQ保证高可用，主要是避免Broker发生单点故障而引起Broker上的消息无法及时消费，RocketMQ采用了主从复制和读写分离机制来保证高可用。
  首先引入Broker主备机制，到达主服务器的消息需要同步到从服务器，这样当主服务器宕机后消费者可以从从服务器拉取消息。
  主服务器启动并在特定端口监听从服务器的连接，从服务器启动的时候主动连接主服务器，主服务器接受客户端的连接并建立相关TCP连接，从服务器主动向主服务器发送待拉取消息偏移量，主服务器解析请求并返回消息给从服务器，然后从服务器保存消息并继续发送新的消息同步请求。
  Rocket MQ的读写分离，消费者首先向主服务器发送拉取消息请求，然后主服务器返回一批消息，然后会根据主服务器负载压力与主从同步情况，向从服务器建议下次拉取是从主服务器拉取还是从服务器拉取。

• 回答：

• 见分析。

题目五

• 题干：如何避免消息中间件故障后引发系统整体故障?
• 分析：

• 这个就是要考察消息中间的高可用

• 回答：

• 参考第四题

题目六

• 题干：如何保证投递出去的消息一定不会丢失?
• 分析：

• 这个依赖于confirm机制，生产端首先需要开启一个confirm模式，接着投递到MQ的消息，如果MQ一旦将消息持久化到磁盘之后，必须也要回传一个confirm消息给生产端。
  这样的话，如果生产端的服务接收到了这个confirm消息，就知道是已经持久化到磁盘了。
  否则如果没有接收到confirm消息，那么就说明这条消息半路可能丢失了，此时你就可以重新投递消息到MQ去，确保消息不要丢失。
  这个还可以引申出at least once 机制，是指每个消息必须投递一次。
  RocketMQ Consumer先pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。

• 回答：

• 就是持久化后一定要给予生成者一个反馈，接收到反馈后就不会重发，没接收到就继续重发。

题目七

• 题干：如何保证投递出去的消息只有一条且仅仅一条，不会出现重复的数据?
• 分析：

• RocketMQ为了追求高性能，并不保证此特性，要求在业务上进行去重，也就是说消费消息要做到幂等性。RocketMQ虽然不能严格保证不重复，但是正常情况下很少会出现重复发送、消费情况，只有网络异常，Consumer启停等异常情况下会出现消息重复。
  kafka可以保证Exactly Only Once这个自己查阅。

• 回答：

• 见分析。

题目八

• 题干：重复消费的消息怎么保证数据的准确性?
• 分析：

• 消费端做好幂等设计。

• 回答：

• 消费端做好幂等设计。

题目九

• 题干：是否需要保证消息的顺序性?需要为什么需要如何保证？不需要为什么不需要？

• 分析：

• 消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了3条消息，分别是订单创建，订单付款，订单完成。消费时，要按照这个顺序消费才能有意义。但是同时订单之间是可以并行消费的。
  RocketMQ可以严格的保证消息有序。

• 回答：

• 见分析。

题目十

• 题干：消费系统宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?
• 分析：

• 参考

• 回答：

• 参考