遇到什么记录什么

1.@requestbody注解的作用

2.@pathvariable注解的作用

3.Eureka的自我保护机制

4.RPC远程调用最核心的是什么

5.@EnableEurekaServer注解的作用

6.EnableDiscoveryClient注解的作用

7.Eureka、Zookeeper、Consul三个注册中心的异同点

8.Ribbon本地负载均衡客户端 VS Nginx服务端负载均衡的区别

9.LB负载均衡（Load Balance）是什么

10.RestTemplate的getForObject()方法和getForEntity()方法的区别

11.Ribbon的负载规则有哪些

12.@Component注解的作用

13.Integer的最大值

13.OpenFeign 默认超时控制时间

ribbon:
#指的是建立连接所用的时间，适用于网络状态正常的情况下，两端连接所用的时间
  ReadTimeout: 5000
#指的是建立连接后从服务器读取到可用资源所用的时间
  ConnectTimeout: 5000

14.SpringCloud 远程调用逻辑：

15.Idea设置每个服务的内存占用：

16.MySQL事务tips：

17.集成Mybatis-plus后分页不好用的问题：

@Configuration
@EnableTransactionManagement
@MapperScan("com.atjixue.gulimall.ware.dao")
public class WareMybatisConfig {
    @Bean
    public PaginationInterceptor paginationInterceptor() {
        PaginationInterceptor paginationInterceptor = new PaginationInterceptor();
        // 设置请求的页面大于最大页后操作， true调回到首页，false 继续请求  默认false
        paginationInterceptor.setOverflow(true);
        // 设置最大单页限制数量，默认 500 条，-1 不受限制
        paginationInterceptor.setLimit(1000);
        // 开启 count 的 join 优化,只针对部分 left join
        paginationInterceptor.setCountSqlParser(new JsqlParserCountOptimize(true));
        return paginationInterceptor;
    }
}

18.解决跨域origin重复问题(未使用nginx): Allow-Origin header contains multiple values... but only one is allowed:

filters:
  - RewritePath=/api/(?<segment>.*),/renren-fast/$\{segment}
  - DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin

19.分布式基础总结：

1、分布式基础概念：

2、基础开发：

3、环境：

4、开发规范：

20.Elasticsearch

21.Feign的调用流程：

22.Nginx代理给网关：

23.压力测试性能指标：

响应时间（Response Time:RT）：

HPS(Hits Per Second)：

TPS(Transaction per Second):

QPS（Query per Second）：

最大响应时间（Max Response Time）：

最小响应时间（Min Response Time）：

90%响应时间（90% Response Time）：

从外部看，性能测试主要关注如下三个指标：

24.影响性能的考虑

25.性能监控分析：

JVM内存模型：

堆（Heap）：

26.Jconsole和Jvisualvm的使用

27.Nginx动静分离

28.配置JVM内存：

29.缓存与分布式锁：

缓存：

30.Redis exception; nested exception is io.lettuce.core.RedisException: io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 46137344 byte(s) of direct memory (used: 58720256, max: 100663296)问题：

springboot 2.0 以后默认是使用lettuce作为操作redis的客户端。使用netty进行网络通信
ettuce的bug导致堆外内存溢出 -Xm300m netty如果没有指定堆外内存，默认使用-Xm300m
可以通过 -Dio.netty.maxDirectMemory进行设置
解决方案：不能使用 -Dio.netty.maxDirectMemory只去调大堆外内存。
 1）、升级lettuce客户端。2）、切换使用jedis

31.缓存穿透、缓存雪崩、缓存击穿：

缓存穿透：

缓存雪崩：

缓存击穿：

32.分布式下如何加锁：

33.Redisson的使用：

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.12.0</version>
</dependency>

public class MyRedissonConfig {
/**
     *所有对Redisson的使用都要通过RedissonClient对象
* */
@Bean(destroyMethod="shutdown")
    RedissonClient redisson() throws IOException {
        // 创建配置
        Config config = new Config();
        // Redis url should start with redis:// or rediss://
        config.useSingleServer().setAddress("redis://0.0.0.0:6379");
        // 根据config对象创建出RedissonClient的实例
        RedissonClient redissonClient = Redisson.create(config);
        return redissonClient;
    }
}

可重入锁：

@ResponseBody
@GetMapping("hello")
public String hello(){
    //1、 获取一把锁，只要锁的名字一样就是用一把锁
    RLock lock = redisson.getLock("my-lock");
    //2、加锁
    lock.lock(); // 阻塞式等待
    try{
        System.out.println("加锁成功，执行业务" + Thread.currentThread().getId());
        Thread.sleep(3000);
    }catch (Exception e){

    }finally {
        //解锁
        System.out.println("释放锁..." + Thread.currentThread().getId());
        lock.unlock();
    }
    return "hello";
}

1）、锁的自动续期，如果业务超长，运行期间自动给锁续上新的30s，不用担心业务时间长锁自动过期被删掉
2）、加锁的业务只要运行完成 就不会给当前锁续期，即使不手动解锁，锁也会默认在30s以后自动删除

34.缓存数据一致性问题：

双写模式：

失效模式：

解决方案：

总结：

35.MD&MD5盐值加密

加盐：

36.社交登录

37.服务处于集群状态，session共享问题

1、session复制

2 客户端存储

3.hash一致性

38.session共享问题-统一存储

39.Session共享问题结局-不同服务，子域session共享

40.SpringSession核心原理：

41.ThreadLoacl - 统一线程共享数据

42.RabbitMQ -消息队列

概述：

点对点式：

• 消息发送者发送消息，消息代理将其放入消息队列，消息接收者从队列中获取消息内容，消息读取后被移除队列

• 消息只有唯一的发送者和接受者，但并不是说只能有一个接受者

发布订阅式：

• 发送者（发布者）发送消息到主题，多个接收者（订阅者）监听（订阅）这个主题，那么就会在消息达到时同时收到消息

JMS（Java Message Service）JAVA消息服务：

• 基于JVM消息代理的规范。ActiveMQ、HornetMQ是JMS实现

• 高级消息队列协议，也是一种消息代码的规范，兼容JMS

• RabbitMQ是AMQP的实现

Spring支持

• spring-jms提供了对JMS的支持

• spring- rabbit提供了对AMQP的支持

• 需要ConnectionFactory的实现来链接消息代理

• 提供JmsTemplate、RabbitTemplate来发送消息

• @JmsLIstener（JMS）、@RabbitListener（AMQP）注解在方法上舰艇消息代理发布消息

• @EnableJms 、 @EnableRabbit开启支持

Spring自动配置

• JmsAutoConfiguration

• RabbitAutoConfiguration

RabbitMQ简介：

• Message：
消息，消息不实具名的，它是由消息头和消息组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode(指出该消息可能需要持久性存储)等

• Publisher:
消息的产生者，也是一个向交换器发布消息的客户端应用程序

• Exchange:
交换器，用来接收生产者发送的消息，并将这些消息路由给服务器中的队列。Exchange有四种类型：direct（默认）、fanout 、topic和headers，不同类型的Exchange转发消息的策略有所区别。

• 引入依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

• 编写配置类（消息序列化）：

@Configuration
public class MyRabbitConfig {
    @Bean
    public MessageConverter messageConverter(){
        return new Jackson2JsonMessageConverter();
    }
}

• 信息写入配置文件：
 

• 如何创建exchange queue binding：使用AmqpAdmin进行创建

public void createExchange() {
     //amqpAdmin
     //Exchange
     //   public DirectExchange(String name, boolean durable, boolean autoDelete, Map<String, Object> arguments)
     // 全参数构造器
     DirectExchange directExchange = new DirectExchange("hello-java-exchange",true,false);
     amqpAdmin.declareExchange(directExchange);
log.info("Exchange[{}]创建成功" ,"hello-java-exchange");
 }

public void createQueue(){
    //public Queue(String name, boolean durable, boolean exclusive, boolean autoDelete, Map<String, Object> arguments)
    Queue queue = new Queue("hello-java-queue",true,false,false);
    amqpAdmin.declareQueue(queue);
log.info("Exchange[{}]创建成功" ,"hello-java-queue");
}

public void createBinding(){
    //public Binding(String destination, DestinationType destinationType, String exchange, String routingKey, Map<String, Object> arguments)
    // 目的地 目的地类型 交换机 路由键 自定义参数
    // 将exchange指定的交换机和destination目的地进行绑定，使用routkey作为路由键
    Binding binding = new Binding("hello-java-queue",Binding.DestinationType.QUEUE,
            "hello-java-exchange","hello.java",null);
    amqpAdmin.declareBinding(binding);
log.info("Exchange[{}]创建成功" ,"hello-java-binding");
}

public void sendMessageTest(){
    // 发送消息 如果发送的消息是个对象 我们会使用序列化机制，将对象鞋出去 必须实现Serializable接口
    OrderReturnReasonEntity orderReturnReasonEntity = new OrderReturnReasonEntity();
    orderReturnReasonEntity.setId(1L);
    orderReturnReasonEntity.setCreateTime(new Date());
    orderReturnReasonEntity.setName("hah");
    String msg = "hello world";
    // 发送的对象类型的消息 可以是一个JSON

    rabbitTemplate.convertAndSend("hello-java-exchange","hello.java",orderReturnReasonEntity);
log.info("消息发送完成{}",orderReturnReasonEntity);
}

43.幂等性处理

44.Feign远程调用丢失请求头问题

45.本地事物失效问题：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

46.分布式事务：

为什么会有分布式事务：

CAP定理与BASE理论

• 一致性(Consistency):
• 在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新的数据副本）

• 可用性(Availability)
• 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

• 区分容错性(Partition tolerance)
• 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）
分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，他们之间可能无法通信。

面临问题：

BASE理论：

• 基本可用（basically Available）
• 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用
• 响应时间上的损失，正常情况下搜索引擎需要在0.5s之内返回给用户响应的查询结果，但是由于故障（比如系统部分机房发生断电或者断网故障），查询结果的响应时间增加到了1～2秒。
• 功能上的损失，购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

• 软状态（Soft State）
• 软状态指的是允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一本一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

• 最终一致性（Eventual Consistency）
• 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

强一致性、弱一致性、最终一致性：

分布式事务几种方案：

• XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低

• XA性能不理想，特别是在交易下链路，往往并发量很高，XA无法满足高并发场景

• XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换会导致主库与备库数据不一致

• 许多nosql也没有支持XA。这让XA的应用场景变得非常狭隘

• 也有3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理）

47.Seata

48.RabbitMQ-延迟队列(实现定时任务)

场景：

常用解决方案：

消息的TTL（Time To Live）

• 消息的TTL就是消息的存活时间

• RabbitMQ可以对队列和消息分别设置TTL
• 对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信
• 如果队列设置了，消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。可以通过设置消息的expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果。

Dead Letter Exchanges(DLX)

• 一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。（什么是死信）
• 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。（basic.reject/basic.nack）requeue = false
• 上面的TTL到了，消息过期了
• 队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。

• Dead Letter Exchanges其实是一种普通的exchange，和创建其他的exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

• 我们既可以控制消息在一段时间后变成死信，又可以控制变成死信的消息被路由到某个指定的交换机，结合二者，其实就可以实现一个延时队列。

49.@RequestBody 只支持PostMapping

50.SpringBoot测试失败并报错: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration

51.java.lang.AssertionError: Response content