每天十道面试题-20200409

╰半夏微凉° 2023-07-24 08:39 20阅读 0赞

### 每天十道面试题-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，所有订单请求全部堆到消息中间件，然后逐步处理。
 *  回答：
 *  > 异步、削峰、解耦。

###### 题目二 ######

*  题干：消息中间件技术选型为什么选择这个中间件？
 *  分析：
 *  > 主要是考虑，团队成员对该中间件的掌握以及维护这个是最基本的，然后业务场景，对并发的要求，对消息顺序性的要求，对消息重试的要求，对消息回溯的要求等等 [传送门][Link 1] 这篇文章从多个维度列举了当下常用的消息中间件的特性。
 *  回答：
 *  > 见分析。

###### 题目三 ######

*  题干：为什么不用其他的呢?技术选型的依据是什么?
 *  分析：
 *  > 参考题目二。
 *  回答：
 *  > 参考题目二。

###### 题目四 ######

*  题干：如何保证消息中间件的高可用性?
 *  分析：
 *  > 对于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可以严格的保证消息有序。
 *  回答：
 *  > 见分析。

###### 题目十 ######

*  题干：消费系统宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?
 *  分析：
 *  > [参考][Link 2]
 *  回答：
 *  > [参考][Link 2]

[Link 1]: https://cloud.tencent.com/developer/article/1430167
[Link 2]: http://www.yq1012.com/shizhan/4898.html