JavaEE进阶总结

目录

一.Springboot和SpringCloud

1. 什么是 spring boot？

2.为什么要用 spring boot？

3.spring boot 核心配置文件是什么？

4.spring boot 配置文件有哪几种类型？它们有什么区别？

5.spring boot 有哪些方式可以实现热部署？

6.jpa 和 hibernate 有什么区别？

7.什么是 spring cloud？

8.spring cloud 断路器的作用是什么？

9.spring cloud 的核心组件有哪些？

10.SpringBoot的核心注解是哪个？它主要由哪几个注解组成的？

11.SpringBoot需要独立的容器运行吗？

12.Spring Boot 的配置文件有哪几种格式？它们有什么区别？

二.RabbitMQ

1.rabbitmq 的使用场景有哪些？

2.rabbitmq 有哪些重要的角色？

3.rabbitmq 有哪些重要的组件？

4.rabbitmq 中 vhost 的作用是什么？

5.rabbitmq 的消息是怎么发送的？

6.rabbitmq 怎么保证消息的稳定性？

7.rabbitmq 怎么避免消息丢失？

8.要保证消息持久化成功的条件有哪些？

9.rabbitmq 持久化有什么缺点？

10.rabbitmq 有几种广播类型？

11.rabbitmq 怎么实现延迟消息队列？

12.rabbitmq 集群有什么用？

13.rabbitmq 节点的类型有哪些？

14.rabbitmq 集群搭建需要注意哪些问题？

15.rabbitmq 每个节点是其他节点的完整拷贝吗？为什么？

16.rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况？

17.rabbitmq 对集群节点停止顺序有要求吗？

18.rabbitMQ工作模式？

三.Kafka

1.kafka 可以脱离 zookeeper 单独使用吗？为什么？

2.kafka 有几种数据保留的策略？

3.kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？

4.什么情况会导致 kafka 运行变慢？

5.使用 kafka 集群需要注意什么？

四.Zookeeper

1.zookeeper 是什么？

2.zookeeper 都有哪些功能？

3.zookeeper 有几种部署模式？

4.zookeeper 怎么保证主从节点的状态同步

5.集群中为什么要有主节点？

6.集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？

7.说一下 zookeeper 的通知机制？

五.Redis

1.redis 是什么？都有哪些使用场景？

2. redis 有哪些功能？

3.redis 和 memecache 有什么区别？

4.redis 为什么是单线程的？

5.什么是缓存穿透？怎么解决？

6.redis 支持的数据类型有哪些？

7.redis 支持的 java 客户端都有哪些？

8. jedis 和 redisson 有哪些区别？

9.怎么保证缓存和数据库数据的一致性？

10.redis 持久化有几种方式？

11.redis 怎么实现分布式锁？

12.redis 分布式锁有什么缺陷？

13.redis 如何做内存优化？

14. redis 淘汰策略有哪些？

15.redis 常见的性能问题有哪些？该如何解决？

16.Redis中的数据持久化策略？

17.Redis为什么要分片？

六.Dubbo

1.Dubbo是什么？

2.Dubbo能做什么？

3.你们公司的double注册中心用的什么？

七.ActiveMQ

1.介绍一下ActiveMQ

2.ActiveMQ 消息发送失败的解决方案，如何保证消息一定 发送成功?

3. 使用 ActiveMQ 的好处?

4.ActiveMQ 项目使用场景

5.ActiveMQ 可以发送的消息类型有哪些?

6.ActiveMQ 心跳机制?

7.ActiveMQ 发送消息方式?

8.MQ用过哪些？了解哪些？

八.数据库部分

1.数据库数据如何备份(数据备份策略)？

2.数据库压力大时，怎么实现高可用？

3.数据库优化策略？

4.什么是Mycat？

九.Ngnix

1.了解Ngnix吗？

2.Nginx 的四个主要组成部分了解吗?

3.Nginx 的特点？

4.介绍一下 Nginx 反向代理

5.说下 nginx 负载均衡？

6.如何配置Nginx?

7.Nginx 使用方法?

十.elasticsearch和solr

1.简述elasticsearch？

2.简述solr？

3.Lucene是什么？

4.elasticsearch与solr在用法上的区别？

5.elasticsearch与solr的比较？

十一.补充部分

1.Ribbon 和 Feign 的区别?

2.什么是服务熔断（Hystrix）？

3.工作中遇到的问题？

4.消息堆积怎么处理？

5.了解MongoDB吗？

6.Jedis和RedisTemplate有什么区别？

7.TCP三次握手和四次挥手的流程？

8.feign与dubbo的区别？

9.说下分布式锁？

10.分布式锁的实现方式有哪些？

---

一.Springboot和SpringCloud

1. 什么是 spring boot？

• 在Spring框架这个大家族中，产生了很多衍生框架，比如 Spring、SpringMvc框架等，Spring的核心内容在于控制反转(IOC)和依赖注入(DI),所谓控制反转并非是一种技术，而是一种思想，在操作方面是指在spring配置文件中创建，依赖注入即为由spring容器为应用程序的某个对象提供资源，比如 引用对象、常量数据等。

• SpringBoot是一个框架，一种全新的编程规范，他的产生简化了框架的使用，所谓简化是指简化了Spring众多框架中所需的大量且繁琐的配置文件，所以 SpringBoot是一个服务于框架的框架，服务范围是简化配置文件。

2.为什么要用 spring boot？

• Spring Boot使编码变简单

• Spring Boot使配置变简单

• Spring Boot使部署变简单

• Spring Boot使监控变简单

3.spring boot 核心配置文件是什么？

• Spring Boot提供了两种常用的配置文件：

  • properties文件

  • yml文件

4.spring boot 配置文件有哪几种类型？它们有什么区别？

• Spring Boot提供了两种常用的配置文件，分别是properties文件和yml文件。相对于properties文件而言，yml文件更年轻，也有很多的坑。可谓成也萧何败萧何，yml通过空格来确定层级关系，使配置文件结构跟清晰，但也会因为微不足道的空格而破坏了层级关系。

5.spring boot 有哪些方式可以实现热部署？

• SpringBoot热部署实现有两种方式：

  • 1.使用spring loaded

  • 1. 使用spring-boot-devtools在项目的pom文件中添加对应依赖（常用）

6.jpa 和 hibernate 有什么区别？

• JPA Java Persistence API，是Java EE 5的标准ORM接口，也是ejb3规范的一部分。 Hibernate，当今很流行的ORM框架，是JPA的一个实现，但是其功能是JPA的超集。 JPA和Hibernate之间的关系，可以简单的理解为JPA是标准接口，Hibernate是实现。那么Hibernate是如何实现与JPA的这种关系的呢。Hibernate主要是通过三个组件来实现的，及hibernate-annotation、hibernate-entitymanager和hibernate-core。 ibernate-annotation是Hibernate支持annotation方式配置的基础，它包括了标准的JPA annotation以及Hibernate自身特殊功能的annotation。 hibernate-core是Hibernate的核心实现，提供了Hibernate所有的核心功能。 hibernate-entitymanager实现了标准的JPA，可以把它看成hibernate-core和JPA之间的适配器，它并不直接提供ORM的功能，而是对hibernate-core进行封装，使得Hibernate符合JPA的规范。

7.什么是 spring cloud？

• 从字面理解，Spring Cloud 就是致力于分布式系统、云服务的框架。Spring Cloud 是整个 Spring 家族中新的成员，是最近云服务火爆的必然产物。 使用 Spring Cloud 开发人员可以开箱即用的实现这些模式的服务和应用程序。这些服务可以任何环境下运行，包括分布式环境，也包括开发人员自己的笔记本电脑以及各种托管平台。

8.spring cloud 断路器的作用是什么？

• 在Spring Cloud中使用了Hystrix 来实现断路器的功能，断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决，如果问题似乎已经得到纠正，应用程序可以尝试调用操作。

• 断路器增加了稳定性和灵活性，以一个系统，提供稳定性，而系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对一个操作，即很可能失败，而不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提高每次改变状态的时间的事件，该信息可以被用来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在打开状态。

9.spring cloud 的核心组件有哪些？

• 1.服务发现——Netflix Eureka

  • 一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。

• 2.客服端负载均衡——Netflix Ribbon

  • Ribbon，主要提供客户侧的软件负载均衡算法。Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。

• 3.断路器——Netflix Hystrix

  • 断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调用操作。

• 4.服务网关——Netflix Zuul

  • 类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

• 5.分布式配置——Spring Cloud Config

  • 这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

10.SpringBoot的核心注解是哪个？它主要由哪几个注解组成的？

• 启动类上面的注解是@SpringBootApplication，它是 Spring Boot 的核心注解，主要组合包含了以下 3 个注解：

  • @SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。

  • @EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源自动配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。

  • @ComponentScan：Spring组件扫描。

11.SpringBoot需要独立的容器运行吗？

• 可以不需要，内置了 Tomcat/ Jetty 等容器。

12.Spring Boot 的配置文件有哪几种格式？它们有什么区别？

• properties 和 .yml，它们的区别主要是书写格式不同。

• 另外.yml 格式不支持 @PropertySource 注解导入配置。

二.RabbitMQ

1.rabbitmq 的使用场景有哪些？

• 1.跨系统的异步通信，所有需要异步交互的地方都可以使用消息队列。就像我们除了打电话（同步）以外，还需要发短信，发电子邮件（异步）的通讯方式。

• 1. 多个应用之间的耦合，由于消息是平台无关和语言无关的，而且语义上也不再是函数调用，因此更适合作为多个应用之间的松耦合的接口。基于消息队列的耦合，不需要发送方和接收方同时在线。在企业应用集成（EAI）中，文件传输，共享数据库，消息队列，远程过程调用都可以作为集成的方法。

• 3.应用内的同步变异步，比如订单处理，就可以由前端应用将订单信息放到队列，后端应用从队列里依次获得消息处理，高峰时的大量订单可以积压在队列里慢慢处理掉。由于同步通常意味着阻塞，而大量线程的阻塞会降低计算机的性能。

• 4.消息驱动的架构（EDA），系统分解为消息队列，和消息制造者和消息消费者，一个处理流程可以根据需要拆成多个阶段（Stage），阶段之间用队列连接起来，前一个阶段处理的结果放入队列，后一个阶段从队列中获取消息继续处理。

• 5.应用需要更灵活的耦合方式，如发布订阅，比如可以指定路由规则。

• 6.跨局域网，甚至跨城市的通讯（CDN行业），比如北京机房与广州机房的应用程序的通信。

2.rabbitmq 有哪些重要的角色？

• RabbitMQ 中重要的角色有：生产者、消费者和代理：

  • 生产者：消息的创建者，负责创建和推送数据到消息服务器；

  • 消费者：消息的接收方，用于处理数据和确认消息；

  • 代理：就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。

3.rabbitmq 有哪些重要的组件？

• 1.ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。

• 2.Channel（信道）：消息推送使用的通道。

• 3.Exchange（交换器）：用于接受、分配消息。

• 4.Queue（队列）：用于存储生产者的消息。

• 5.RoutingKey（路由键）：用于把生成者的数据分配到交换器上。

• 6.BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

4.rabbitmq 中 vhost 的作用是什么？

• vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。

5.rabbitmq 的消息是怎么发送的？

• 首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息，客户端和 rabbit server 之间会创建一个 tcp 连接，一旦 tcp 打开并通过了认证（认证就是你发送给 rabbit 服务器的用户名和密码），你的客户端和 RabbitMQ 就创建了一条 amqp 信道（channel），信道是创建在“真实” tcp 上的虚拟连接，amqp 命令都是通过信道发送出去的，每个信道都会有一个唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。

6.rabbitmq 怎么保证消息的稳定性？

• 提供了事务的功能。通过将 channel 设置为 confirm（确认）模式。

7.rabbitmq 怎么避免消息丢失？

• 1.消息持久化

• 2.ACK确认机制

• 3.设置集群镜像模式

• 4.消息补偿机制

8.要保证消息持久化成功的条件有哪些？

• 1.声明队列必须设置持久化 durable 设置为 true.

• 2.消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。

• 3.消息已经到达持久化交换器。

• 4.消息已经到达持久化队列。

• 以上四个条件都满足才能保证消息持久化成功。

9.rabbitmq 持久化有什么缺点？

• 持久化的缺地就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。

10.rabbitmq 有几种广播类型？

• 三种广播模式：

  • 1.fanout: 所有bind到此exchange的queue都可以接收消息（纯广播，绑定到RabbitMQ的接受者都能收到消息）；

  • 2.direct: 通过routingKey和exchange决定的那个唯一的queue可以接收消息；

  • 3.topic:所有符合routingKey(此时可以是一个表达式)的routingKey所bind的queue可以接收消息；

11.rabbitmq 怎么实现延迟消息队列？

• 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；

• 使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。

12.rabbitmq 集群有什么用？

• 集群主要有以下两个用途：

  • 1.高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；

  • 2.高容量：集群可以承载更多的消息量。

13.rabbitmq 节点的类型有哪些？

• 磁盘节点：消息会存储到磁盘。

• 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。

14.rabbitmq 集群搭建需要注意哪些问题？

• 1.各节点之间使用“–link”连接，此属性不能忽略。

• 2.各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。

• 3.整个集群中必须包含一个磁盘节点。

15.rabbitmq 每个节点是其他节点的完整拷贝吗？为什么？

• 不是，原因有以下两个：

  • 1.存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；

  • 2.性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

16.rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况？

• 如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：

  • 不能创建队列

  • 不能创建交换器

  • 不能创建绑定

  • 不能添加用户

  • 不能更改权限

  • 不能添加和删除集群节点

• 唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。

17.rabbitmq 对集群节点停止顺序有要求吗？

• RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。

18.rabbitMQ工作模式？

• 1.Work模式：一个生产者，多个消费者，每个消费者获取到的消息唯一。

• 2.订阅模式:一个生产者发送的消息会被多个消费者获取。

• 3.路由模式:

  • (1)发送消息到交换机并且要指定路由key

  • (2)消费者将队列绑定到交换机时需要指定路由key

• 4.通配符模式:将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“*”只匹配一个词。

• 5.RPC模式:在RabbitMQ中RPC的实现也是很简单高效的，现在我们的客户端、服务端都是消息发布者与消息接收者。

三.Kafka

1.kafka 可以脱离 zookeeper 单独使用吗？为什么？

• kafka 不能脱离 zookeeper 单独使用，因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。

2.kafka 有几种数据保留的策略？

• kafka 有两种数据保存策略：按照过期时间保留和按照存储的消息大小保留。

3.kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？

• 这个时候 kafka 会执行数据清除工作，时间和大小不论那个满足条件，都会清空数据。

4.什么情况会导致 kafka 运行变慢？

• 1.cpu 性能瓶颈

• 2.磁盘读写瓶颈

• 3.网络瓶颈

5.使用 kafka 集群需要注意什么？

• 1.集群的数量不是越多越好，最好不要超过 7 个，因为节点越多，消息复制需要的时间就越长，整个群组的吞吐量就越低。

• 2.集群数量最好是单数，因为超过一半故障集群就不能用了，设置为单数容错率更高。

四.Zookeeper

1.zookeeper 是什么？

• zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 google chubby 的开源实现，是 hadoop 和 hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

2.zookeeper 都有哪些功能？

• 1.集群管理：监控节点存活状态、运行请求等。

• 2.主节点选举：主节点挂掉了之后可以从备用的节点开始新一轮选主，主节点选举说的就是这个选举的过程，使用 zookeeper 可以协助完成这个过程。

• 3.分布式锁：zookeeper 提供两种锁：独占锁、共享锁。独占锁即一次只能有一个线程使用资源，共享锁是读锁共享，读写互斥，即可以有多线线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。zookeeper可以对分布式锁进行控制。

• 4.命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。

3.zookeeper 有几种部署模式？

• zookeeper 有三种部署模式：

  • 1.单机部署：一台集群上运行；

  • 2.集群部署：多台集群运行；

  • 3.伪集群部署：一台集群启动多个 zookeeper 实例运行。

4.zookeeper 怎么保证主从节点的状态同步

• zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。 zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

5.集群中为什么要有主节点？

• 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。

6.集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？

• 可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

7.说一下 zookeeper 的通知机制？

• 客户端端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。

五.Redis

1.redis 是什么？都有哪些使用场景？

• Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

• 使用场景：

  • 1.数据高并发的读写

  • 2.海量数据的读写

  • 3.对扩展性要求高的数据

2. redis 有哪些功能？

• 数据缓存功能

• 分布式锁的功能

• 支持数据持久化

• 支持事务

• 支持消息队列

3.redis 和 memecache 有什么区别？

• 1.memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

• 2.redis的速度比memcached快很多

• 3.redis可以持久化其数据

4.redis 为什么是单线程的？

• 因为 cpu 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 cpu 又不会成为瓶颈，那就顺理成章地采用单线程的方案了。

• 关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

• 而且单线程并不代表就慢 nginx 和 nodejs 也都是高性能单线程的代表。

5.什么是缓存穿透？怎么解决？

• 缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

• 解决方案：最简单粗暴的方法如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们就把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

6.redis 支持的数据类型有哪些？

• string、list、hash、set、zset。

7.redis 支持的 java 客户端都有哪些？

• Redisson、Jedis、lettuce等等，官方推荐使用Redisson。

8. jedis 和 redisson 有哪些区别？

• 1.Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持。

• 2.Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

9.怎么保证缓存和数据库数据的一致性？

• 合理设置缓存的过期时间。

• 新增、更改、删除数据库操作时同步更新 Redis，可以使用事物机制来保证数据的一致性。

10.redis 持久化有几种方式？

• Redis 的持久化有两种方式，或者说有两种策略：

  • 1.RDB（Redis Database）：指定的时间间隔能对你的数据进行快照存储。

  • 2.AOF（Append Only File）：每一个收到的写命令都通过write函数追加到文件中。

11.redis 怎么实现分布式锁？

• Redis 分布式锁其实就是在系统里面占一个“坑”，其他程序也要占“坑”的时候，占用成功了就可以继续执行，失败了就只能放弃或稍后重试。

• 占坑一般使用 setnx(set if not exists)指令，只允许被一个程序占有，使用完调用 del 释放锁。

12.redis 分布式锁有什么缺陷？

• Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

13.redis 如何做内存优化？

• 尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。

• 比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。

14. redis 淘汰策略有哪些？

• 1.volatile-lru：从已设置过期时间的数据集（server. db[i]. expires）中挑选最近最少使用的数据淘汰。

• 2.volatile-ttl：从已设置过期时间的数据集（server. db[i]. expires）中挑选将要过期的数据淘汰。

• 3.volatile-random：从已设置过期时间的数据集（server. db[i]. expires）中任意选择数据淘汰。

• 4.allkeys-lru：从数据集（server. db[i]. dict）中挑选最近最少使用的数据淘汰。

• 5.allkeys-random：从数据集（server. db[i]. dict）中任意选择数据淘汰。

• 6.no-enviction（驱逐）：禁止驱逐数据。

15.redis 常见的性能问题有哪些？该如何解决？

• 主服务器写内存快照，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以主服务器最好不要写内存快照。

• Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，主从库最好在同一个局域网内。

16.Redis中的数据持久化策略？

• 如果使用时允许丢失部分数据则使用RDB模式，效率高，也是redis默认的策略。如果不允许丢失数据则采用AOF模式，它的安全性高，但是效率低。

17.Redis为什么要分片？

• 实现动态内存扩容

六.Dubbo

1.Dubbo是什么？

• Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是用于服务调用的。说白了就是个远程服务调用的分布式框架。

• 其核心部分包含:

  • 1.远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

  • 2.集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

  • 3.自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2.Dubbo能做什么？

• 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

• 2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

• 3.服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

• 主要核心部件:

  • 1.Remoting: 网络通信框架，实现了 sync-over-async 和request-response 消息机制

  • 2.RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能

  • 3.Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

3.你们公司的double注册中心用的什么？

• 用的是 zookeeper,你们用了几台 zookeeper?我们开发的时候用的是 1 台服务器，然后上线 的时候用的是 3 台,一个主的两个备用的,你知道为什么是 3 台吗? 知道啊,因为 zookeeper 集群是投标选举机制,必须是奇数的,超过半数以上,主的挂掉,备用的就自动启动了,咱们 互联网思维,集群不就是为了解决服务器不宕机的问题么.

七.ActiveMQ

1.介绍一下ActiveMQ

• 是基于 Java 中的 JMS 消息服务规范实现的一个消息中间件

• ActiveMQ 是支持 JMS 规范的一个开源技术，它支持好多通讯协议，像我们最常用的 TCP 和 UDP，它都支持，activeMQ 支持多种通讯协议 TCP/UDP 等。对于 TCP 协议，我们知道 TCP 有一个三次握手，所谓的三次握手可以这样来理解，比如 A 和 B 建立连接时，首先 A 向 B 发出一个同步请求，然后 B 回复一个同步请求应答，最后 A 回复一个确认信息。

2.ActiveMQ 消息发送失败的解决方案，如何保证消息一定 发送成功?

• Mq 中的消息基本不会丢失，偶尔有丢失的可以通过日志定位，通过手动操 作方式重新处理。 同时也可以配置数据库来解决，将数据库中的处理失败的消息状态设置为未 发送，然后通过定时任务再次重复发送。这样可以通过消息状态来确定消息是否 发送成功。 第一种用数据库配合着解决： 怎么配合呢咱们这边不是发送的商品的 ID 么，在发送之前把 ID 记录在数据 库里面去，然后设置一个状态字段，0 代表这个消息发送中,然后监听端进行消 费,消费成功后把这个字段在改为 1.然后就是几种突发情况,第一种情况比如说 突然断电了然后我的消息首先是记录在数据库里面了，然后他的那个状态是不是 为 0 啊，然后我们有一个用 quartz 写的定时器,每隔 5 分钟会去数据库跑个批然 后把状态为 0 的数据,再重新发送一遍消息,直到消费成功为止. 第二种解决： 在发送消息的时候设置提交的方式，改成手动提交的方式，在后台改成 commit 状态改成手动方式，如果发送成功的话，然后 commit 手动提交方式。

3. 使用 ActiveMQ 的好处?

• 减轻服务器压力,降低项目之间的耦合度(解耦),是做异步的.

4.ActiveMQ 项目使用场景

• 对于 ActiveMQ 在我们开发中,用它来降低过我们的项目耦合度,主要应用到这么 几个场景，比如，我们的项目现在都是分布式的，咱们不可能在一个模块中实现 所有的功能，就拿商品管理模块来说,当对商品做添加，修改，删除操作时，其 他模块也有可能有相关连的变化，比如前台模块中的搜索，商品信息变了，索引 库中内容也应该有相应的变化，这个时候呢，我们就需要用到一个通信机制，那 ActiveMQ 这种类型的框架我们就恰好需要的，可以在商品操作时，发送一个消 息说我商品信息改变了，当然需要指明哪一个商品发生了变化，发送对应的商品 id 就行，在前台模块中，我们配置一个消息接收端，当接收到消息时，对索引 库做下修改就行。 当然，除了商品添加同步更新索引库，像商品详情模块,在商品审核通过以后, 想消息队列中发送了一个商品 id 到消息队列中,pageService 工程中有一个监听 类,可以生成相应的静态页面,,还有订单模块也有用到过，当执行生成订单，进 行银行扣款，扣款成功，减库存啊，这种类型的操作，都可以通过 ActiveMQ 发 生消息来实行同步操作

5.ActiveMQ 可以发送的消息类型有哪些?

• 我记得可以发送的消息类型有,

  • TextMessage--一个字符串对象

  • MapMessage--一套名称-值对

  • ObjectMessage--一个序列化的 Java 对象

  • BytesMessage--一个字节的数据流

  • StreamMessage -- Java 原始值的数据流

• 我项目中用过 text map object 这三个类型

6.ActiveMQ 心跳机制?

• 还有这个 ActiveMQ 还有一个心跳的机制，这种机制可以判断收发双方链路是否通畅，它内 部使用的机制是双向心跳，也就是 ActiveMQ 的生产者和消费者都进行相互心跳。心跳这里 会产生两个线程，一个是“ReadCheck”“WriteCheck”，它们都是 timer 类型，每隔一段时 间都会被调用一次. 其实这个 ActiveMQ 的信息还是挺多的,比如它发送消息能实现即时发送,还能实现定时,延时 发送.

7.ActiveMQ 发送消息方式?

• 对于 ActiveMQ 发送消息的方式，是分为两种的，其实它也是符合 JMS 规范的，就是点对点 和订阅消息类型，对于点对点，每个消息只能有一个消费者，这种方式是基于队列的，如果 消息不被消费，就会一直阻塞在队列中，只有当消费者消费之后消息才会消失。对于订阅方式，它是基于主题 topic 的，可以有多个消费者，类似于广播，只要你订阅了， 就能够收到这个消息，如果发的时候还没启动消费者，那这个消息就会被错过。

8.MQ用过哪些？了解哪些？

• 我们用过的消息队列有 ActiveMQ 和 RabbitMQ,我还知道有个 kafka 大数据 里用的,这三种消息队列处理速度上来说 Kafka 大于 RabbitMQ 大于 ActiveMQ, 从安全上来讲: ActiveMQ 大于 RabbitMQ 大于 Kafaka, 我知道银 行也用的 RabbitMQ 挺安全的 我给你说下 ActiveMQueue 和 RabbitMQ 他俩的区 别吧, ActiveMQ 他发消息的方式有两种,一种是推拉式的 Queue,还有一种是 发布式的(Topic), 区别在于推拉式的发送,只允许有一个消费端进行消费,如 果不消费的话就一直存在队列中,订阅式的是发送一个消息,可以有多个消费端, 如果没有消费的话,他也不会一直保留到消息队列中,这两种我开发的时候都用过

八.数据库部分

1.数据库数据如何备份(数据备份策略)？

• 1.冷备份：定期将数据库中的文件进行转储，定期进行数据备份

• 2.热备份：搭建数据库主从结构，挡住库数据发生改变时，从库根据主库的二进制日志文件进行备份。

• 3.双机热备：数据库互为主从，数据库打理服务器对主库进行心跳检测，实现数据的高可用，为了防止主库宕机后发生雪崩现象。

2.数据库压力大时，怎么实现高可用？

• 1.用数据库代理服务器搭建数据库的读写分离进行分流，读取从库数据，写数据在主库，可用的数据库代理服务器有Amoeba和Mycat，由于大量的用户的数据库操作都需要通过数据库来完成，造成数据库负载过高，因为数据库操作中查询的操作占很大的比重。

• 2.数据库实现双机热备。

3.数据库优化策略？

• 1.优化sql语句 where 左连接 右连接 内连接 尽可能根据主键查询，尽可能少用2.关联查询

• 3.创建索引

• 4.添加缓存 redis

• 5.定期进行数据转储

• 6.分库分表

4.什么是Mycat？

• 是一个数据库中间件，实现读写分离，分库分表和数据库故障迁移。

九.Ngnix

1.了解Ngnix吗？

• Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务 器。 Nginx 主要提供反向 代理、负载均衡、动静分离(静态资源服务)等服务

• 我们项目上线之后用的是一个负载均衡，现在用的比较多了，就我了解的像新浪，搜狐， 快手都有用到，其实就是一个负载均衡服务器，反向代理，我们在访问项目的时候是不需 要直接访问服务器的，而是访问 ngnix 服务器，由 ngnix 来决定访问哪一个服务器，在 ngnix.config 配置文件里面配置代理服务器，想代理几台就代理几台，就那台服务器配置 高点的话，可以配置一个 weight,就是配置一个权重，把权重配置的稍微大点，如果是服务 器的配置低的话呢，我们也可以配置 weight 低一点， 像项目后期的测试这块，我也都有跟进过。我们用的是 windows 版本的 ngnix,包括在 linux 上的也都有实现过，最终项目上线的时候，是上线到 linux 上的，ngnix 用的是两台服务器， 其实还有一台是三台，一主一备，还有一个高可用的一个服务，让 ngnix 的主节点和备用 服务器呢，来传输一个心跳协议，来检测状态。如果主节点挂掉的话，就是从的，那个备 用服务器会立马启动起来工作，然后运维人员对主节点进行相应的维修，再次重新启动， 再转回主节点

2.Nginx 的四个主要组成部分了解吗?

• Nginx 二进制可执行文件：由各模块源码编译出一个文件

• Nginx.conf 配置文件：控制 Nginx 行为

• acess.log 访问日志： 记录每一条 HTTP 请求信息

• error.log 错误日志:

3.Nginx 的特点？

• 1、高并发，高性能

• 1. 可扩展性好（模块化设计，第三方插件生态圈丰富）

• 1. 高可靠性（可以在服务器行持续不间断的运行数年）

• 1. 热部署（这个功能对于 Nginx 来说特别重要，热部署指可以在不停止 Nginx 服务的情 况下升级 Nginx）

• 1. BSD 许可证（意味着我们可以将源代码下载下来进行修改然后使用自己的版本）

4.介绍一下 Nginx 反向代理

• 他就是一个反向代理服务器,其实它的优点就是内存占用少,并发访问能力强,我知道的新浪, 斗鱼,好这些大公司都使用这个技术,它底层实现是 c 语言实现的.我们主要用到 nginx 两大 主要的功能吧,一个是反向代理,一个是负载均衡,先说一下这个反向代理,咱们还得先说一 下正向代理,其实咱们平时调试开发都是正向代理,只不过我们不说这个词.比如吧,我们访 问一台 tomcat,默认端口号是 8080,那我们访问的时候可能就是 localhost:8080,这样顺着 来呢，就可以理解成一个正向代理,就这样理解哈,这个时候，如果我们想要再来一台服务器 呢,我们可以配一下,把端口号改成 8081,通过访问不同的端口号来访问, 但是当我们项目要上线的时候，如果需要把一个项目如果部署到两台服务器上，比如淘宝，这么大，它的主 界面不可能是在一台服务器上放着，就不能是访问 8080 或者 8081 这些端口了，这个时候， 需要有一个代理的服务器，能够给这两台服务器做一个代理，直接不需要进行标明，就可以 访问到任意一台服务器，找到这个主界面。这里呢，这个代理就可以代理这些服务器了，这 个时候这个代理，我们可以理解成反向代理。反向代理严格的概念是通过代理服务器来接收 网路上的请求，然后将请求转发给内部网路的服务器。而 nginx 可以干这个活，做这个代理， 我们可以在 nginx 中配置端口，ip 或者域名指向这些不同端口，甚至不同 ip 的服务器。这 就是反向代理这个概念。

5.说下 nginx 负载均衡？

• Nginx 还有一个重要的功能叫做负载均衡，我们做服务器的集群，怎样保证集群中服务器被 均等的进行访问呢，不能说我们认为搭建好了服务器的集群它就会均衡的去访问，这个时候 我们可以统一的去访问 nginx 这个服务器，在 nginx 的配置信息中，去配置好这些服务器， 它配置文件是这样的，只要你配上，默认访问的比率就是一样的，这个就是负载均衡，当然 nginx 更厉害的是可以配置权重，比如说哈，我两台服务器，其中一台性能比另外一个性能 好 2 倍，那我是不是应该访问性能好的服务器频率更高一些，咱们就可以在 nginx 的配置文 件中配置一个 weight 属性，指定权重。当然还有其他一些配置的，比如有些服务器需要整 修，那咱们就可以配置某台服务器暂时 down 掉，这样用户访问的时候，就不会访问到这台 服务器，当修好之后，我们在把这个配置信息干掉就行了。

6.如何配置Nginx?

• 我们配置 nginx 是在 nginx 安装目录下的 conf 下有一个 nginx.conf 文件，主要是修改这个 配置文件，比如咱们配置反向代理和负载均衡服务器，配置一个 proxy_pass 指向代理服务 器，配一下upstream server指向要访问的ip和端口，这个可以配置多个ip,可以设置weight 权重什么的

7.Nginx 使用方法?

• 其实 nginx 服务器搭建这一块是由公司的运维去做的,我原来在自己的虚拟机里也配置过, 可以搭建两台 nginx 服务器,主备关系,用那个 keepalived 管理主备服务器,keepalived 其 实就是让主备服务器之间发送心跳协议,保证 nginx 永不宕机.

十.elasticsearch和solr

1.简述elasticsearch？

• ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

2.简述solr？

• Solr是Lucene面向企业搜索应用的扩展

• 基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎

3.Lucene是什么？

• Lucene 是一个基于 Java 的全文信息检索工具包，目前主流的搜索系统Elasticsearch和solr都是基于lucene的索引和搜索能力进行。

4.elasticsearch与solr在用法上的区别？

• elasticsearch:

  • 1.要使用必须配置Java_HOME的环境变量

  • 2.ik分词器等高级功能由插件完成

  • 3.自启动

• Solr是用Java编写、运行在Servlet容器（如 Apache Tomcat 或Jetty）的一个独立的全文搜索服务器。

  • 1.拷贝solr war包至tomcat

  • 2.拷贝日志jar包

  • 3.配置solrHome和solrCore\

  • 4.在war包中web.xml中配置solrhome的位置

  • 5.启动tomcat

5.elasticsearch与solr的比较？

• solr

  • 优点

    • 1、Solr有一个更大、更成熟的用户、开发和贡献者社区。

    • 2、支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。

    • 3、Solr比较成熟、稳定。

    • 4、不考虑建索引的同时进行搜索，速度更快。

  • 缺点

    • 建立索引时，搜索效率下降，实时索引搜索效率不高。

• Elasticsearch

  • 优点

    • 1、Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。

    • 2、Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。

    • 3、处理多租户（multitenancy）不需要特殊配置，而Solr则需要更多的高级设置。

    • 4、Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。

    • 5、各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

  • 缺点

    • 还不够自动，不适合当前新的Index Warmup API

• 总结：

  • 1、当单纯的对已有数据进行搜索时，Solr更快。

  • 2、当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。

  • 3、随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

  • 4、Solr的架构不适合实时搜索的应用。

  • 5、Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式

  • 6、Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch

  • 7、Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用

十一.补充部分

1.Ribbon 和 Feign 的区别?

• 1.Ribbon都是调用其他服务的，但方式不同。

• 2.启动类注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients

• 3.服务指定的位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。

• 4.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。Feign需要将调用的方法定义成抽象方法即可。

2.什么是服务熔断（Hystrix）？

• 熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇形链路的某个微服务出错不可用或者响应 时间太长时，会进行服务的降级，从而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路在Spring Cloud框架中。熔断机制通过Hystrix实现。Hystrix会监控微服务之间调用的状况，当失败的调用到一定阈值时，（缺省是5秒内调用20次失败，就会启动熔断机制）熔断机制的注解是@HystrixCommand

3.工作中遇到的问题？

• 1、内存溢出，可以调节 tomcat 内存解决。还要找出代码中内存溢出的漏洞，一般是流没 有关闭或者死循环；

• 2、数据库连接超出最大连接量：修改 mysql 配置文件的最大连接数；

• 3、代码编译失败、缓存：清理 Eclipse 编译缓存、清理 tomcat 缓存、清理浏览器缓存。

• 4、tomcat 启动端口号被占用：打开任务管理器，杀进程；

• 5、tomcat 启动超时：修改启动时间；

4.消息堆积怎么处理？

• 消息发送主要涉及三方:producer/consumer/broker,所以发生消息积压要从这三方来看

  • 1、broker

    • 其实不用太关注消息队列，因为消息队列本身的处理能力要远远大于业务系统的处理能力。主流消息队列的单个节点，消息收发的性能可以达到每秒钟处理几万至几十万条消息的水平，还可以通过水平扩展 Broker 的实例数成倍地提升处理能力。

  • 2、producer端性能优化

    • producer端对消息积压的影响不大，但是对producer端发送消息的性能有要求。一般是先执行自己的业务逻辑，最后再发送消息。如果说，你的代码发送消息的性能上不去，你需要优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。

    • 对于发送消息的业务逻辑来说，设置批量发送及批量发送的大小可以提高发送端的发送性能Producer 发送消息的过程，Producer 发消息给 Broker，Broker 收到消息后返回确认响应，这是一次完整的交互。假设这一次交互的平均时延是 1ms，我们把这 1ms 的时间分解开，它包括了下面这些步骤的耗时：发送端准备数据、序列化消息、构造请求等逻辑的时间，也就是发送端在发送网络请求之前的耗时；发送消息和返回响应在网络传输中的耗时；Broker 处理消息的时延。如果是单线程发送，每次只发送 1 条消息，那么每秒只能发送 1000ms / 1ms * 1 条 /ms = 1000 条 消息，这种情况下并不能发挥出消息队列的全部实力。

    • 无论是增加每次发送消息的批量大小，还是增加并发，都能成倍地提升发送性能。至于到底是选择批量发送还是增加并发，主要取决于发送端程序的业务性质。发生消息积压后，producer端服务降级，关闭一些非核心业务，减少消息的产生。

  • 3、consumer端性能优化

    • 发生消息积压，主要原因就是消费端的消费能力跟不上生产端的生产速度。

    • 容consumer实例，注意扩容后必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的，因为在队列中的消费是单线程的，如果只扩容了consumer实例，没有扩容队列数量，则不会有效果的。等待积压的消息被消费，恢复到正常状态，撤掉扩容服务器。

5.了解MongoDB吗？

• MongoDB是一个基于分布式文件存储的数据库。由C 语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。

• MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

6.Jedis和RedisTemplate有什么区别？

• Jedis是Redis官方推荐的面向Java的操作Redis的客户端，而RedisTemplate是SpringDataRedis中对JedisApi的高度封装。

• SpringDataRedis相对于Jedis来说可以方便地更换Redis的Java客户端，比Jedis多了自动管理连接池的特性，方便与其他Spring框架进行搭配使用如：SpringCache

7.TCP三次握手和四次挥手的流程？

• 三次握手：

  • （1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

  • （2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

  • （3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

• 四次挥手:

  • 所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

8.feign与dubbo的区别？

• 一、相同点

  • Dubbo 与 Feign 都依赖注册中心、负载均衡。

• 二、区别

  • 1、协议

    • Dubbo：

      • 支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。非常灵活。

      • 默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。

    • Feign：

      • 基于Http传输协议，短连接，不适合高并发的访问。

  • 2、负载均衡

    • Dubbo：

      • 支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。

      • 配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。

      • 负载均衡的算法可以精准到某个服务接口的某个方法。

    • Feign：

      • 只支持N种策略：轮询、随机、ResponseTime加权。

      • 负载均衡算法是Client级别的。

  • 3、容错策略

    • Dubbo：

      • 支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。

    • Feign：

      • 利用熔断机制来实现容错的，处理的方式不一样。

9.说下分布式锁？

• 分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。

• 分布式锁要满足哪些要求呢？

  • 1.排他性：在同一时间只会有一个客户端能获取到锁，其它客户端无法同时获取

  • 2.避免死锁：这把锁在一段有限的时间之后，一定会被释放（正常释放或异常释放）

  • 3.高可用：获取或释放锁的机制必须高可用且性能佳

10.分布式锁的实现方式有哪些？

• 1.基于数据库实现

  • 基于数据库来做分布式锁的话，通常有两种做法：

    • 1.基于数据库的乐观锁

    • 2.基于数据库的悲观锁

• 2.基于Redis实现

  • 基于Redis实现的锁机制，主要是依赖redis自身的原子操作

    • 当某个进程设置成功之后，就可以去执行业务逻辑了，等业务逻辑执行完毕之后，再去进行解锁。解锁很简单，只需要删除这个key就可以了，不过删除之前需要判断，这个key对应的value是当初自己设置的那个。另外，针对redis集群模式的分布式锁，可以采用redis的Redlock机制。

• 3.基于ZooKeeper实现

  • 其实基于ZooKeeper，就是使用它的临时有序节点来实现的分布式锁。

    • 原理就是：当某客户端要进行逻辑的加锁时，就在zookeeper上的某个指定节点的目录下，去生成一个唯一的临时有序节点， 然后判断自己是否是这些有序节点中序号最小的一个，如果是，则算是获取了锁。如果不是，则说明没有获取到锁，那么就需要在序列中找到比自己小的那个节点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是，则获取锁，如果不是，则重复上述步骤。

    • 当释放锁的时候，只需将这个临时节点删除即可。