dubbo和zookeeper常见面试题，mq面试必备

dubbo和zookeeper常见上一面考试试卷？

1.Dubbo的工作流程是什么？

答：Dubbo的工作流程涵盖：provider向注册中心去注册自己为一个服务，consumer去注册中心订阅服务，注册中心会公告consumer注册好的服务，consumer会将provider的地点位置等信息拉取到本地缓存，consumer去调用provider，consumer和provider都异步的公告监控中心。

2.Dubbo的通信原理是什么？

答：Dubbo底层使用hessian2进行二进制序列化进行远程调用，Dubbo底层使用Netty框架进行异步通信。

3.Dubbo负载均衡策略有什么？

答：Dubbo负载均衡策略涵盖：random loadbalance、roundrobin loadbalance、leastactive loadbalance、consistanthash loadbalance等。

4.ZooKeeper是什么？有哪些作用？

答：ZooKeeper是一个分布式协调服务，可以用于分布式应用程序的协调和管理。它提供了一个分布式的、开放的、可靠的数据存储，用于存储和管理分布式应用程序的配置信息、命名服务、状态信息等。

5.ZooKeeper的特点是什么？

答：ZooKeeper的特点涵盖：高可用性、高性能、数据完全一样性、顺序访问、可靠性、容错性等。

6.ZooKeeper的工作原理是什么？

答：ZooKeeper的工作原理是根据ZAB协议，它将数据存储在内存中，并将数据同步到全部的ZooKeeper服务器上，保证数据的完全一样性。ZooKeeper使用了一种根据观察者模式的机制，当数据出现变化时，会公告全部的观察者。

7.ZooKeeper的节点类型有什么？

答：ZooKeeper的节点类型涵盖：持久节点、临时节点、持久顺序节点、临时顺序节点。

8.ZooKeeper如何保证数据的完全一样性？

答：ZooKeeper使用了ZAB协议来保证数据的完全一样性，它将数据存储在内存中，并将数据同步到全部的ZooKeeper服务器上，保证数据的完全一样性。

1. Dubbo 的原理是什么？2. 什么是 Dubbo 客户端的负载均衡？3. 什么是 Dubbo 服务治理？4. Dubbo 框架的架构是什么样的？5. 什么是 Dubbo 协议？6. Dubbo 服务当中是如何达到通信的？7. 什么是 Zookeeper？8. Zookeeper 的原理是什么？9. Zookeeper 的应用场景是什么？10. Zookeeper 客户端和服务端当中是如何交互的？

mq面试考点重要内容及核心考点？

主要有3点：解耦、异步、削峰（限流）。

实际上就是在服务与服务当中增多了一个中间件，可以达到上面的三种用途。



解耦：我们看到，服务A强依赖服务B和C，当服务B或者C挂掉后，会直接致使服务A的不可用，这明显不是我们所希望的。例如服务的最后一步是记录日志，但是，该服务挂了，虽然日志服务和主流服务没有肯定的业务联系，但是，因为代码的耦合性过高，直接致使整个服务响应失败。

异步：假设服务A本身执行只10ms，服务B需5ms，服务C（日志服务）需1s。同样的，一个和业务本身无关的服务过长的响应时间致使了整体服务的响应超时。

削峰：假设因为服务C只是记录日志的，服务器配置很低，1s只可以处理往年条数据，但是，人流高度聚集时段，每秒的请求高达10万笔，过高的请求可能会造成服务器崩溃。

可以看到，实际上上面所讲的三种情况，都很类似，连起来可以这么理解。人流高度聚集时段致使服务C运行越来越慢，出现了“异步”所说的问题，假设长时间没处理，可能造成“解耦”所说的情况，即服务挂掉。

在增多了MQ以后，我们可在服务A执行完核心业务后，将后续处理的业务数据打入消息队列中，然后完全就能够返回成功。然后日志服务从消息队列中取到对应的消息进行一定程度的处理就可以。这样就达到了“解耦”和“异步”。在人流高度聚集时段，全部的数据都会打入消息队列中，而日志服务只根据自己的消费水平（往年条/s）取数据就好，保证了服务的平滑稳定。

二、MQ选型

主流的MQ有4种，ActiveMQ、RabbitMQ、RocketMQ和Kafka。不过ActiveMQ虽然框架成熟、曾经是MQ中的王牌，但是，目前官方的维护频率越来越低，国内各大公司已经很少才用了，另外，吞吐量不高（比kafka低一个数量级），存在消息丢失的情况，故此，目前新项目很少会采取了。

RabbitMQ是用ErLang语言开发的，性能上是最好的，但是，因为ErLang语言不是主流语言，二次开发难度非常高，不少想要按照目前的实际情况进行二次开发的公司很少采取。不过假设只是简单使用，还是不错的，毕竟它的延时是最少的；还RabbitMQ有一个最大的好处是它具有可视化界面，操作维护很方便。

RocketMQ是阿里开源的产品，经过了不少高并发项目标考验（如双十一），性能上是有保证的。纯Java编写，维护性高。我理解的它和kafka最大的不一样有两点，一是它支持事务；二是集群结构不完全一样，它没有主从切换，当leader挂掉后，存在一定的感知时间，然后切换到follower上。

kafka的特点就是高吞吐量，大多数情况下配合大数据信息内容服务平台类的系统来进行实时数据计算、日志采集，在日志收集领域是其实的标准。

此外springCloud全家桶中，有一个springCloudStream消息驱动框架，该框架很好的封装了MQ操作的有关API，减轻了开发者在MQ方面的代码量，不过该框架只封装了RabbitMQ和kafka这两种MQ。

综合上面所说得出，假设需对MQ传输提供事务支持或者处理高并发下的业务解耦，建议采取RocketMQ，微服务框架是dubbo，应该也建议用RocketMQ（这个没测过，个人猜测，毕竟都是阿里的产品）。假设是要做日志收集等工作，建议采取kafka。中小型公司使用springCloud全家桶开发的项目中，建议采取RabbitMQ（或者kafka）。

以上是查资料总结的，因为我平日间都是为了让用的kafka，故此，后面都以kafka作为例子了。

三、重复消费

重复消费在MQ中是一个重点问题，这个问题是如何出现的？

kafka中有一个消息偏移量offset，每当消费者消费完一条消息时，执行commit，会将offset+1。假设一条消息在消费完以后暂时还没有commit offset，突发宕机，会让zookeeper觉得该条消息没有被消费。致使消费者重启后重复消费以前的数据。

如何不要？

不要重复消费的问题，与同一个服务被多次调用的问题类似，就是如何处理服务的幂等性。总体有请看下方具体内容哪些方案：

1、利用数据库的唯一性管束。

2、将数据存入redis中，利用redis天然的幂等性，然后再将数据从redis同步到数据库中

3、生产者发消息时增多一个唯一id（例如UUID），消费者消费成功后将该UUID存入redis中，每一次消费前先查看该UUID是不是存在。

四、消息丢失

消息丢失同样也是MQ中是一个重点问题。因为系统中存在生产者、消费者和MQ本身三个组件，故此，需从这三个方面分别讨论。

MQ本身丢失：因为kafka的集群是leader/follower模式，leader先接受消息后，再同步给follower，假设leader接收到消息后出现宕机，没来得及同步数据给follower，这时依靠选举机制出现了新的leader，但是，它已经永远的失去了这条消息。为了不要这样的情况出现，还要更改kafka的配置，利用kafka自己的特性来处理。

第一给topic设置replication.factor参数：这个值一定要大于1，要求每个partition一定要有至少2个副本。

然后在kafka服务端设置min.insync.replicas参数：这个值一定要大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才可以保证leader挂了还有一个follower。

然后在producer端设置acks=all：这个是要求每条数据，一定要是写入全部replica后面，才可以觉得是写成功了

最后在producer端设置retries=MAX（很大很大很大的一个值，无限次重新尝试的意思）：这个是要求但凡是写入失败，就无限重新尝试，卡在这里了。

这样配置以后，完全就能够保证唯有全部的副本数据都同步成功后，才觉得消息发送成功，不要了leader挂掉的情况。

消费者丢失：kafka有一个自动提交机制，每一次接受到消息后自动提交offset。假设消息还是没有处理就挂掉了，但zk却已经接收到消费成功的公告，明显不合理，故此，要不要使用kafka的自动提交，改成手动提交。

生产者丢失：明显，假设配置了acks=all以后，生产者是不会出现消息丢失的。

此外查资料发现RabbitMQ和kafka的消息丢失情况不一样，这里补充一个RabbitMQ的处理方法。

MQ本身丢失：因为RabbitMQ没有集群配置，故此，只可以依靠持久化到本地的方法来进行备份。假设接收到消息还没来得及备份就挂掉了，就可以致使消息丢失。不过这个可能性很低。假设出现了，能用到生产者丢失的方法处理，见下。

消费者丢失：出现原因不说了。可以采取RabbitMQ提供的ack机制，即关闭RabbitMQ自动ack，然后通过api来调用就行，在确认处理完消息后，手动提交ack公告MQ。

生产者丢失：可能实质上的困难就是生产者发送消息后，互联网传输有问题致使了数据丢失。为了不要这样的情况，大多数情况下会开启事务机制，保证数据完全一样性，但是，事务机制因为是同步的，会导致系统性能下降，故此，可以借鉴分布式事务的观念，即confirm机制。生产者发送消息后，开启异步接受MQ的反馈，收到后，默认消息发送成功，超时后触发消息重发机制。

五、如何保证消息顺序消费。

这个很简单，只要保证每个消费者或者每个处理线程都对应一个队列就可以。

六、消息积压如何处理。

毕竟流量人流高度聚集时间存在不长，只要最初规划MQ的空间时考虑到流量人流高度聚集的容量，大多数情况下是不出现积压的，除非因为代码bug或者消费者宕机。

这时为了迅速处理积压的消息，我们除了修正bug和重启服务器以外，还要有有早一点定好的应急方案，即临时扩容消费者，增多消费者处理速度。还不可以设置消息的TTL，保证消息一直存在。

实在没办法了的终极处理方案，就是抛弃部分消息，然后过了人流高度聚集以后，依靠日志等方法人肉维护。。

最后，说一个我以前的公司，为了不要重复消费和消息丢失的处理方案，就是在生产者发送消息前和消费者接收消息后，在本地记录一条数据，然后定时对比两者的差异，来保证这两个问题不会出现。同样该方案也可以用于处理积压，完全可以抛弃消息，最后依靠生产者记录的数据进行维护。这样的方法比较合适业务分离状态的，如购物场景，只要保证用户下单成功就可以，后续的出库，赠加积分，赠送优惠券等功能稍缓缓也不碍事，但是，假设是时效性非常高的业务，例如商品查询，可能商品描述、商品价格、商品图片都不一样的服务在处理，假设一个服务不可以正常返回，那这个业务就没办法正常开展。这样的情况，就建议采取限流策略了。

解耦：我们看到，服务A强依赖服务B和C，当服务B或者C挂掉后，会直接致使服务A的不可用，这明显不是我们所希望的。例如服务的最后一步是记录日志，但是，该服务挂了，虽然日志服务和主流服务没有肯定的业务联系，但是，因为代码的耦合性过高，直接致使整个服务响应失败。

异步：假设服务A本身执行只10ms，服务B需5ms，服务C（日志服务）需1s。同样的，一个和业务本身无关的服务过长的响应时间致使了整体服务的响应超时。

削峰：假设因为服务C只是记录日志的，服务器配置很低，1s只可以处理往年条数据，但是，人流高度聚集时段，每秒的请求高达10万笔，过高的请求可能会造成服务器崩溃。

软件测试面试问题及回答技巧？

提问一：先自我讲解一下吧！

应对思路：

1、面试必考试题。

2、自我讲解途中，一定要与简历符合。

3、放送心态，尽可能时候口语化表达。

4、紧密紧跟核心竞争力，不谈无关、无用的主要内容。

5、逻辑条理清晰，层次分明。

6、最好面试前背熟。

提问二：你的业余爱好有那些?

应对思路：

1、 一般招聘者问这个问题的原因，大约是觉得业余爱好能反映出应聘者的部分性格、观念、心态等特点；

2、一定不要说没有业余爱好；

3、 不要说令人感觉不好的爱好；

4、 不要说类似于读书、听音乐、网络之类的爱好，可能会出现应聘者性格孤僻的印象。

5、 最好有一部分户外、社交、运动类的业余爱好来提高形象。

提问三：最崇拜的人是谁?

应对思路：

1、 最崇拜的人，能很大程度上反映希望成为什么样的人；

2、 不要说没有崇拜对象。

3、 不要说崇拜自己；

4、 不要说崇拜虚构的、或不了解名的人；

5、 不要说崇拜明显具有负面形象的人；

6、 最好能说出什么品质、思想领自己崇拜。

试题试卷备考资料及辅导课程

试题试卷培训班名师辅导课程