springcloud面试题库 Spring cloud面试集锦

大家好，感谢邀请，今天来为大家分享一下springcloud面试题库的问题，以及和cloud面试集锦的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

Java程序员面试中容易被问哪些问题

1.前台后台都做吗?10分

这一般是我的第一个问题,超过90%的人会回答:"都做,后台多一点,前台少一点"

这不是我想要的答案,鬼都知道程序员都要多少涉及一下前台,后台更不用说了.

碰到过一个聪明人,他是这么回答的:前台js写的比较熟练,html的框架模板也能搭建的非常整齐美观,只是特效能力比较差

这个问题我不想过多讨论,加分但不减分

2.事务,什么是事务,为何用事务10分

大部分面试者,就会举各种各样的例子(比如银行存钱,这个最多)来说明这个问题,其实他们都理解.

但这不是我想要的答案,我期望的答案只有一句:"保证数据的一致性和完整性",可惜只有5%左右的人答出来了

这个问题可以大概了解出面试者的分析能力,以及语言总结能力,还有他们对这个玩意的理解程度

答不出减分,举例子不加分

3.面向切面(AOP),原理是什么10分

这个就是对技能的掌握程度了

大部分又是举例子,什么找中介啊之类的,其实就是来掩盖他们懂一点实现逻辑,但是不知道源码怎么实现的.

但还真是有学霸能把代理的原理讲出来,非常好.

答不出减分,举例子不加分,讲出原理双倍分.

4.两个项目之间如何通信10分

很基础的问题,答上来就有分,说明你接触或者了解过网络

5.在上个问题基础之上问,碰到乱码怎么解决,utf-8和gbk可以直接转换么10分

大部分应聘者到这里基本就开始胡扯了.有说声明字符串编码接收的,有说改项目编码的,各种各样五花八门.

更有甚者,utf-8和gbk可以直接转换...

直接说明了他们完全没有遇到过此类问题,也并不了解编码.

答不出不减分,胡扯减分,答对双倍分.

6.简述一项技术或设计模式的原理20分

这个几乎是送分的,但90%的人答不出.我很不解.

答不出减分,答出加分

-----------------------------------------------------------------------------------------------------------------------------

问完以上几个问题大概可以判断出应聘者的技术程度

不管怎么样

希望多锻炼自己的口才与技术.

spring cloud面试题及答案

1、为什么人们会犹豫使用微服务？

我见过许多开发者在这个问题上摸索。毕竟，在面试微服务架构师角色时，他们会被问到这个问题，所以承认它的缺点可能有点棘手。以下是一些很好的答案：

它们需要大量协作-微服务需要大量的合作。不同的微服务模块，可能分散在不同的团队，团队之间需要始终保持良好的同步。

他们需要建立繁重的架构-系统是分布式的，架构涉及很多。他们需要过多的计划来处理操作开销-如果您计划使用微服务架构，则需要为操作开销做好准备。需要熟练的专业人员，他们可以支持异构分布的微服务。

2、SpringCloud是什么

1、SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

2、SpringCloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

常见的Java面试题有哪些，如何能达到高薪就业

如果你想找一个不错的JAVA工作，下面这些知识是你面试必须要掌握的；

常用的线程通讯工具，比如CountDownLatch、CyclicBarrier、Semaphore等JDK并发包常用工具，比如ConcurrentHashMap、BlockingQueue、DelayQueue等JDK常用类源码解析，比如HashMap、ConcurrentHashMap等常用框架以及源码分析，Spring、Springboot常用微服务架构，Dubbo、Springcloud等常用互联网组件，zk、redis、rabbitMQ、kafka等常见算法最后一个比较重要的就是，心态和缘分

如果以上你都掌握并拥有了，相信你会有一个不错的offer。

欢迎大家在评论区沟通交流！

面试java岗位的时候，你被提过哪些问题

程序员朋友由于每天面对和电脑沟通的语言，有时候可能忽略了一些自然语言的技巧，而在面试中，一些说话的套路往往会帮求职者增分不少，Java就业课中，就有关于面试技巧的分析和参考：

一、面试官：在我们这儿工作，您希望有什么样的薪资待遇？

提示：了解该公司所在地区、所属行业、公司规模等信息，你的薪水要求应该在该公司所在地区、行业、公司规模相应的薪水范围之内。尽可能提供一个你期望的薪水范围，而不是具体的薪金数。

求职者：其实工资并不是我决定工作机会的唯一因素，如果您一定要我回答这个问题，只能说我希望以我所受的教育背景及工作经验，我希望我的工资不低于年薪50,000元。

二、面试官：你认为每年加薪的幅度是多少？

提示：通常,比较可靠的回答是:你希望收入的增长和生活水平的提高保持一致。你还应该提到，你的业绩将是加薪的主要因素。

求职者：总体来说，取决于我个人的业绩和公司的业绩（盈利状况）。但一般而言，至少和生活水平的提高保持一致。

三、面试官：你上一份工作的收入是多少？

提示：有时候面试人员希望得到一个比较明确的答案。记住，在陈述你的收入时，要把你的整个福利收入也加在上面。在有的公司福利收入可以使你的年收入增加30%或更多。

求职者：我过去的三年内一直在ABC公司工作，我是大学一毕业就在这个公司的，当时并没有管理经验。这三年中，我积累了很多管理和财务方面的技巧。现在ABC公司给我的薪水是非常富有竞争性的。

四、面试官：你愿意降低你的标准吗？

提示：如果这确实是你非常希望得到的工作，那么，你应该考虑在开始时工资有所降低。

应强调你可以把工作做得很好，并设法了解公司调整你薪水的时间。另外，对你能够接受的极低数额应心里有数，但千万不要把这个数字告诉给面试人员。

求职者：由于我对该职位非常感兴趣，我可以考虑接受低一些的薪水，你也需要时间让我证明我的能力。我相信我可以干得十分出色，如果我能证明我的能力，你是否会考虑对我的薪水作一些调整呢，比如说，在三个月后。

五、面试官：你认为我们提供给你的薪水如何？

提示：在回答这个问题之前，首先确定这是否是正式聘用的工资数额，也许面试人只是想了解你的工资要求。如果是正式聘用的工资数额，你要确定自己是否能够接受这个数额。

在西方国家，多数雇主希望你能跟他们进一步商量；而在亚洲国家，则相反。如果这个数目大大低于你的期望，可以有技巧性地询问其它的福利项目是怎样的。

求职者：这个数字跟我期望的非常接近，不过我的期望值要稍高些。您是否可以提供一个大致的薪资范围？

六、面试官：能否告诉我，你的工资调整纪录？

提示：在这个问题中，面试人员只是想知道是否你一直原职不变，或者说是否你不断得到晋升的机会。所以，尽量避免提供薪资具体数额，除非他们要求。

求职者：N年来，我一直在ABC公司工作，曾得到X次职务提升。ABC公司每年薪资调整的幅度不是太大，但由于我的工作总是十分优秀，每年的薪资调整都接近调整的很高水平。我目前的工资已比我开始工作的头一年提高XX%。

mq面试必背知识点

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

其实就是在服务与服务之间增加了一个中间件，可以实现上面的三种用途。

?

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

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

削峰：假如由于服务C只是记录日志的，服务器配置较低，1s只能处理2000条数据，但是高峰时段，每秒的请求高达10万笔，过高的请求会导致服务器崩溃。

可以看到，其实上面所讲的三种情况，都很类似，连起来可以这么理解。高峰时段导致服务C运行越来越慢，产生了“异步”所说的问题，如果长时间没解决，可能会导致“解耦”所说的情况，即服务挂掉。

在增加了MQ以后，我们可以在服务A执行完核心业务后，将后续处理的业务数据打入消息队列中，然后就可以返回成功。然后日志服务从消息队列中取到对应的消息进行处理即可。这样就实现了“解耦”和“异步”。在高峰时段，所有的数据都会打入消息队列中，而日志服务只需要按照自己的消费水平（2000条/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。如果一条消息在消费完以后尚未commitoffset，突发宕机，会让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，保证消息一直存在。

实在没办法了的终极解决方案，就是抛弃部分消息，然后过了高峰以后，依靠日志等方式人肉维护。。。

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

Spring boot是Java程序员必须掌握的框架之一么

毫不夸张的说：是的。

目前，不管是个人开发项目还是企业开发项目，如果选择的是Java语言，那我们第一个想到的就是用SpringBoot框架开发，因为用它太快太爽了。几分钟就可以将一个Web后端的项目跑起来。而我们只需要写业务代码就好了。这对于程序员来说简直就是天大的福利。

想想我们用SpringMVC的时候，是多么的痛苦。虽然SpringMVC也是非常优秀的框架（这也是必须要掌握的Java框架），但是基于XML文件的配置实在是太繁琐。启动一个JavaWeb项目，我们需要写一大堆的xml文件，spring.xml、application.xml、web.xml、springmvc-servlet.xml等等，不胜其烦。而且即便这些东西都配置好了，项目还不一定能启动起来。很多程序员应该都碰到过这个问题，bean加载的问题、数据源配置的问题、注解扫描路劲的问题，等等。反正，即使再NB的程序员，没个半个一个小时，跑步起来基于SpringMVC框架的项目。（但是这不影响它成为一个非常优秀的Java框架）。

而SpringBoot完全抛弃了繁琐的xml，在SpringBoot的项目中，几乎看不到xml文件。干净清爽的配置让人欲罢不能，这也是为什么SpringBoot目前这么火的原因，也是现阶段，Java程序员必须要掌握的框架。

最后总结一句：SpringBoot的好，谁用谁知道。

关于springcloud面试题库和cloud面试集锦的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。