蚂蚁金服P6面试 - 好文

1、自我介绍、自己做的项目和技术领域

2、项目中的监控：那个监控指标常见的有哪些？

性能测试需要使用不同的工具，结合系统日志，监控服务器、应用等方面的多项指标。以下阐述监控指标、监控工具、瓶颈分析。

服务端监控指标

性能测试通常需要监控的指标包括：

服务器 Linux（包括CPU、Memory、Load、I/O）。

数据库：Mysql（缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数）。

中间件：1.tomcat 2、nginx 3、memcache（包括线程数、连接数、日志）。

网络：吞吐量、吞吐率。

应用： jvm内存、日志、Full GC频率。

客户端监控指标

LoadRunner：用户执行情况、场景状态、事务响应时间、TPS、吞吐量等。

测试机资源：CPU、Memory、网络、磁盘空间。

常用监控工具

Jstat

监控java 进程GC情况，判断GC是否正常。

JConsole

监控java内存、javaCPU使用率、线程执行情况等，需要在JVM参数中进行配置。

JMap

监控java程序是否有内存泄漏，需要配合eclipse插件或者MemoryAnalyzer来使用。

JProfiler

全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等，需要在JVM参数中进行配置。

Nmon

全面监控linux系统资源使用情况，包括CPU、内存、I/O等，可独立于应用监控。

Probe

全面监控tomcat的线程、内存、JVM CPU 使用率、OS 和 JVM内存使用率、交换区使用率、每30秒内接收到的请求数目等等

Memadim

1. 服务器参数监控：STATS、SETTINGS、ITEMS、SLABS、SIZES实时刷新

2. 服务器性能监控：GET、DELETE、INCR、DECR、CAS等常用操作命中率实时监控

3. 支持数据遍历，方便对存储内容进行监视

4. 支持条件查询，筛选出满足条件的KEY或VALUE

性能分析

分析信息来源

5. 监控工具所采集的信息。包括TPS、响应时间、用户并发数、JVM内存、Full
GC频率、tomcat连接数，数据sql执行时间、memcache的命中率、nginx的连接数等。

6. 应用服务器的日志。包括错误日志、超时日志等。

7. 项目配合人员所提供的信息。包括DBA提供的数据库监控信息、开发人员提供的代码逻辑信息。

分析标准

1.通过性能指标的表现形式，分析性能是否稳定。比如：

2.响应时间是否符合性能预期，表现是否稳定。

3.应用日志中，超时的概率，是否在可接受的范围之内。

8. TPS维持在多大的范围内，是否有波形出现，标准差有多少，是否符合预期。

9. 服务器CPU、内存、load是否在合理的范围内，等等。

分析工具

对于部分性能指标，可借助自动分析工具，统计出数据的总体趋势：

1、LoadRunner analysis 分析

LoadRunneranalysis是loadrunner的一个部件，用于将运行过程中所采集到的数据生成报表，主要用于采集TPS、响应时间、吞吐量、服务器资源使用情况等变化趋势。

2、Memory Analyzer分析

Memory Analyzer工具可以解析Jmap dump出来的内存信息，查找是否有内存泄漏。

3、nmon_analyser分析

nmon工具可以采集服务器的资源信息。列出CPU、MEM、网络、I/O等资源指标的使用情况。

4、MONyog分析

通过此工具我们能够跟踪到执行比较慢的sql语句，并且可以分析出sql语句执行时扫描的行数，使用的索引情况。

3、微服务涉及到的技术以及需要注意的问题有哪些？

微服务条目   技术   备注
服务开发   Springboot、Spring、SpringMVC
服务配置与管理   Netflix公司的Archaius、阿里的Diamond等
服务注册与发现   Eureka、Consul、Zookeeper等
服务调用   REST、RPC、gRPC
服务熔断器   Hystrix、Envoy等
负载均衡   Ribbon、Nginx等
服务接口调用（客户端调用服务发简单工具）   Feign等
消息队列   kafka、RabbitMQ、ActiveMQ等
服务配置中心管理   SpringCloudConfig、Chef等
服务路由（API网关）   Zuul等
服务监控   Zabbix、Nagios、Metrics、Spectator等
全链路追踪   Zipkin、Brave、Dapper等
服务部署   Docker、OpenStack、Kubernetes等
数据流操作开发包   SpringCloud Stream（封装与Redis，Rabbit、Kafka等发送接收消息）
事件消息总线
SpringCloud Bus

使用微服务时的注意事项

在微服务架构带了很多好处的同时，你需要认识到的很重要的一点，你正在进入分布式计算的世界。分布式计算总是一个复杂的课题，微服务也不例外。在开始使用微服务时，有几件事你需要注意到。

复杂性增加

在微服务架构中，有很多可移动的组件，所以对服务的管理将变得更加复杂。相比于单节点应用的部署，你要部署成百上千的服务，还要让它们在一起无缝的工作。这需要服务注册和服务发现解决方案，以便一个新的或者更新的服务能够让自己被系统知道，能够被其他服务检测到。你也需要确保所有的服务都启动并且在运行当中，没有耗尽磁盘空间或者其他资源，并且保证足够的性能。所有的服务通常都会需要负载均衡，并且使用同步或者异步的消息发送来进行通讯。集群管理和编排工具会帮助你解决一些问题，但是也需要你了解这些工具是如何进行工作的。在这系列博客的第二部分，我们将更深入的了解集群管理和编排如何帮助微服务进行工作的。

网络拥塞和延迟

微服务用来通讯的API使用的是标准协议，比如HTTP，所以网络成为重要因素。想象一下在一个应用中有数百个服务，通常一个请求就会跨多个不同的服务，不难看出，如果网络方面没有给予足够的重视的话，将会对应用的整体性能造成多大的影响。另一个经常被忽略的地方是数据的序列化和反序列化。有时，相同的数据从一个服务传递到另一个服务，它会被序列化和发序列化多次，从而大大增加了网络的延迟。有几种模式可以使用，比如数据缓存和服务，来限制请求的数量。对于序列化问题，你可以使用高效的序列化格式，并且在整个服务框架中使用这个共用的格式。这可能会在服务间传递数据时减少一些步骤，不需要再次序列化。

数据一致性

因为每一个微服务通常都会有它自己的状态存储，所以你必须要面临分散数据所带来的数据一致性和完整性挑战。考虑下面的场景，订单服务所引用的数据在另一个服务当中，比如产品目录服务，你就需要维护该服务中的数据完整性。现在你在每个服务中都有一些相同的数据，必须要保证一致性；如果一个服务节点中的数据变更，其他节点中的数据必须一起进行变更。如果在产品目录服务中的数据被删除或者更新，比如有效产品项的数量，订单服务就需要知道这种变化。处理这种一致性挑战，以及诸如此类的数据一致性概念，可能很难得到正确的结果，但是幸运的是，这个问题已经被解决了。比如，你可以使用事件源或者通知服务之类的模式，将变化的数据发布给已经订阅这种变化和更新的数据消费服务。

容错和弹性

微服务应用的特性之一是，即便在发生灾难性故障时，它仍能够实现容错。由于在网络中存在很多微服务，因此，在微服务架构中，故障也更为普遍，也更具挑战性。你可能想知道，这是怎么发生的呢？因为微服务通常都运行在它们自己的进程或者容器当中，其他的微服务是不会直接影响到它的进程的。所以，一个坏的微服务怎么会击倒整个应用？我们来看个例子，如果一个微服务花费太长时间来进行相应，在服务调用中耗尽所有的线程资源，它就会引起整个调用链的级联故障。对故障进行合适的处理，也会对应用正常运行时间的SLA产生影响。我们假设你的应用需要有99.9%的正常运行时间的SLA，也就是说每个月只允许大约44分钟的停机。你的应用包含3个微服务，每个都提供99.9%的正常运行时间。每一个服务都有可能在不同的时间出现停止服务，你就会看到潜在的停机时间大约是132分钟，明显影响了整个应用正常运行时间的SLA。

要进行故障处理，让你的应用实现容错，你需要实现弹性模式，比如超时、重试、熔断机制和隔离机制，这对于开发人员来说都是非常具有挑战性的。

诊断

在微服务应用中，日志和追踪需要一个合理的策略。需要对日志聚合和分析进行认真的思考，因为微服务应用中有成百上千个服务，生成了大量的日志。此外，请求通常会跨越多个服务，所以，找到一种方法在整个系统中对请求进行标记非常重要，让你能够看清跨越所有服务的整个请求。这通常都是通过使用关联或者传递给所有下游服务的活动ID来实现的，每一个服务都会将这个ID写入它的日志。由于服务是由不同的团队开发的，所以确定一种统一的日志格式也很重要。微服务应用的总体诊断与调试是很有挑战性的，必须在一开始就计划好。在本系列的第三部分，我们将介绍一些诊断的最佳实践。

版本控制

在单体系统中，调用一个接口的代码通常与接口的实现部署在一起。接口的中断变更通常是在集成测试或者构建期间被捕获。在微服务世界中，一个微服务接口的变更不需要调用它的微服务立即进行处理，因为他们可能有不同的发布节奏。为了保证调用服务仍然能够按照预期进行工作，需要整个团队考虑并且认可服务版本控制技术。

DevOps

现金的DevOps，自动化和监控是微服务运营成功的关键。在生产环境中进行测试通常是一个目标，实现这个目标需要更多的强调监控，使我们能够快速的检测到异常和问题，并且根据需进行回滚。在自动化方面进行投资，使用诸如Blue-Green
Deployment、Canaries、A/B
Testing和特性标志等工具和最佳实践，非常重要。建立起一个定义良好的工作流，让开发和运营一起工作，带来敏捷、高质量的发布，非常有挑战性。本系列博客的第三部分将对DevOps的流程进行更详细的介绍。

4、注册中心你了解了哪些？

微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。现就微服务中注册中心的选型做一下记录。

当下实现微服务主要有两种选择，DUBBO和Spring Cloud，他们分别选择zookeeper和eureka作为注册中心。

一、什么是CAP定理

在分布式系统领域有个著名的CAP定理：C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性。这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。

二、Zookeeper

Zookeeper是著名Hadoop的一个子项目，很多场景下Zookeeper也作为Service发现服务解决方案。

很多场景下Zookeeper也作为Service发现服务解决方案。Zookeeper保证的是CP，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将就无法获得数据了。所以说，Zookeeper不能保证服务可用性。

诚然，对于大多数分布式环境，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。

三、Eureka

Eureka本身是Netflix开源的一款提供服务注册和发现的产品，并且提供了相应的Java封装。Eureka保证的AP，在它的实现中，节点之间是相互平等的，部分注册中心的节点挂掉也不会对集群造成影响，即使集群只剩一个节点存活，也可以正常提供发现服务。哪怕是所有的服务注册节点都挂了，Eureka
Clients上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用是足够健壮的。

对于服务发现场景来说：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。

所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。

5、consul 的可靠性你了解吗？

6、consul 的机制你有没有具体深入过？有没有和其他的注册中心对比过？

7、项目用 Spring 比较多，有没有了解 Spring 的原理？AOP 和 IOC 的原理

8、Spring Boot除了自动配置，相比传统的 Spring 有什么其他的区别？

Spring Boot可以建立独立的Spring应用程序；
内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作了。
无需再像Spring那样搞一堆繁琐的xml文件的配置；
可以自动配置Spring；
提供了一些现有的功能，如量度工具，表单数据验证以及一些外部配置这样的一些第三方功能；
提供的POM可以简化Maven的配置；

9、Spring Cloud 有了解多少？

Spring Cloud是一个微服务框架，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

Spring Cloud对微服务基础框架Netflix的多个开源组件进行了封装，同时又实现了和云端平台以及和Spring
Boot开发框架的集成。

Spring Cloud为微服务架构开发涉及的
配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性token，全局一致性锁，leader选举，分布式session，集群状态
管理等操作提供了一种简单的开发方式。

Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。

* Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等
* Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud
Config联合实现热部署。
* Spring Cloud
Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
* Netflix
Eureka：一个基于rest服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。
* Netflix
Hystrix：容错管理工具，实现断路器模式，通过控制服务的节点,从而对延迟和故障提供更强大的容错能力。
* Netflix Ribbon：客户端负载均衡的服务调用组件。
* Netflix Feign：基于Ribbon和Hystrix的声明式服务调用组件。
* Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。
* Netflix
Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
* Spring Cloud for Cloud
Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
* Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
* Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。
* Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
* Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
* Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
* Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
* Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
10、Spring Bean 的生命周期

11、HashMap 和 hashTable 区别？

1.Hashtable是线程安全的，它的每个方法中都加入了Synchronize方法

2.HashMap是继承自AbstractMap类，而HashTable是继承自Dictionary类。不过它们都实现了同时实现了map、Cloneable（可复制）、Serializable（可序列化）这三个接口

3.当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap。ConcurrentHashMap虽然也是线程安全的，但是它的效率比Hashtable要高好多倍。因为ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定

4.HashMap的get过程是先得到key的hash值，再把这个hash值与length-1按位与（取余），得到table数组的下标。取出这个下标值的key，与传入的key比较，如果相同那就是这个了。如果不同呢，那就沿着这个单向链表向后找，直到找到或找到结束也找不到。这里的length是有特点的，是2的n次方。

5.HashMap扩容机制是在put时，容量不够用的时候。因为每个元素都是一个单向链表，所以map里放的实际数量总是大于等于申请的空间。

6.HashMap可以接受null键值和值，而Hashtable则不能。

7.HashMap是非synchronized所以HashMap很快。

8.hashcode相同，所以两个对象是相等的，HashMap将会抛出异常，或者不会存储它们。然后面试官可能会提醒他们有equals()和hashCode()两个方法，并告诉他们两个对象就算hashcode相同，但是它们可能并不相等。一些面试者可能就此放弃，而另外一些还能继续挺进，他们回答“因为hashcode相同，所以它们的bucket位置相同，‘碰撞’会发生。因为HashMap使用链表存储对象，这个Entry(包含有键值对的Map.Entry对象)会存储在链表中。”这个答案非常的合理，虽然有很多种处理碰撞的方法，这种方法是最简单的，也正是HashMap的处理方法

9.当一个map填满了75%的bucket时候，和其它集合类(如ArrayList等)一样，将会创建原来HashMap大小的两倍的bucket数组，来重新调整map的大小，并将原来的对象放入新的bucket数组中。这个过程叫作rehashing，因为它调用hash方法找到新的bucket位置
。

10.当重新调整HashMap大小的时候，确实存在条件竞争，因为如果两个线程都发现HashMap需要重新调整大小了，它们会同时试着调整大小。在调整大小的过程中，存储在链表中的元素的次序会反过来，因为移动到新的bucket位置的时候，HashMap并不会将元素放在链表的尾部，而是放在头部，这是为了避免尾部遍历(tail
traversing)。如果条件竞争发生了，那么就死循环了。这个时候，你可以质问面试官，为什么这么奇怪，要在多线程的环境下使用HashMap呢？
12、Object 的 hashcode 方法重写了，equals 方法要不要改？

13、Hashmap 线程不安全的出现场景

14、线上服务 CPU 很高该怎么做？有哪些措施可以找到问题

15、JDK 中有哪几个线程池？顺带把线程池讲了个遍

16、SQL 优化的常见方法有哪些

17、SQL 索引的顺序，字段的顺序

18、查看 SQL 是不是使用了索引？（有什么工具）

19、TCP 和 UDP 的区别？TCP 数据传输过程中怎么做到可靠的？

20、说下你知道的排序算法吧

21、查找一个数组的中位数？

22、项目中你学到了什么技术？（把三项目具体描述了很久）

23、微服务划分的粒度

24、微服务的高可用怎么保证的？

25、常用的负载均衡，该怎么用，你能说下吗？

26、网关能够为后端服务带来哪些好处？

27、Spring Bean 的生命周期

28、xml 中配置的 init、destroy 方法怎么可以做到调用具体的方法？

29、反射的机制

30、Object 类中的方法

31、hashcode 和 equals 方法常用地方

32、对象比较是否相同

33、hashmap put 方法存放的时候怎么判断是否是重复的

34、Object toString 方法常用的地方，为什么要重写该方法

35、Set 和 List 区别？

36、ArrayList 和 LinkedList 区别

37、如果存取相同的数据，ArrayList 和 LinkedList 谁占用空间更大？

38、Set 存的顺序是有序的吗？

39、常见 Set 的实现有哪些？

40、TreeSet 对存入对数据有什么要求呢？

41、HashSet 的底层实现呢

42、TreeSet 底层源码有看过吗？

43、HashSet 是不是线程安全的？为什么不是线程安全的？

44、Java 中有哪些线程安全的 Map？

45、Concurrenthashmap 是怎么做到线程安全的？

46、HashTable 你了解过吗？

47、如何保证线程安全问题？

48、synchronized、lock

49、volatile 的原子性问题？为什么 i++ 这种不支持原子性？从计算机原理的设计来讲下不能保证原子性的原因

50、happens before 原理

51、cas 操作

52、lock 和 synchronized 的区别？

53、公平锁和非公平锁

54、Java 读写锁

55、读写锁设计主要解决什么问题？

56、你项目除了写 Java 代码，还有前端代码，那你知道前端有哪些框架吗？

57、MySQL 分页查询语句

58、MySQL 事务特性和隔离级别

59、不可重复读会出现在什么场景？

60、sql having 的使用场景

61、前端浏览器地址的一个 http 请求到后端整个流程是怎么样？能够说下吗？

62、http 默认端口，https 默认端口

63、DNS 你知道是干嘛的吗？

64、你们开发用的 ide 是啥？你能说下 idea 的常用几个快捷键吧？

65、代码版本管理你们用的是啥？

66、git rebase 和 merge 有什么区别？

67、你们公司加班多吗？

热门工具换一换