每天十道面试题-20200409-蒲公英云

每天十道面试题-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可以严格的保证消息有序。
回答：
见分析。