SpringBoot基础

1、springboot自动配置原理
（1）配置类和配置属性：
通过在类上添加 @Configuration 注解，声明这是一个 Spring 配置类；
通过在方法上添加 @Bean 注解，声明该方法创建一个 Spring Bean；
@ConfigurationProperties 注解，声明这是一个配置属性类，且能够将配置文件中指定前缀的配置项批量注入到该类中。
（2）条件注解：
 @ConditionalOnWebApplication，配置类需要在当前项目是 Web 项目的条件下，才能生效；
 @ConditionalOnClass 条件注解，表示当前配置类需要在类路径下有指定类的条件下，才能生效。
（3）启动 Spring Boot 应用的时候，有个非常重要的组件 SpringFactoriesLoader 类，会读取 META-INF 目录下的 spring.factories 文件，获得每个框架定义的需要自动配置的配置类。

2、Spring Boot jar 包的启动运行原理：
一般通过SpringBoot提供的Maven插件spring-boot-maven-plugin 进行打包，该插件会将配置项写入到MANIFEST.MF中，从而能让 spring-boot-loader 的JarLaunch类完成 Spring Boot 应用的引导和启动。（其中，Java 规定可执行的 jar 包禁止嵌套其它 jar 包，但是SpringBoot打成的jar包的中 BOOT-INFO 目录下实际有SpringBoot应用依赖的所有jar包，而spring-boot-loader 很大的一个作用就是解决 jar 包里嵌套 jar 的情况，如何加载到其中的类。）

3、Lombok
通过使用其定义的注解，自动生成常见的冗余代码，尤其是在POJO上。
（1）@Data 注解，添加在类上，是 5 个 Lombok 注解的组合。
为所有属性，添加 @Getter、@Setter 注解的效果
添加@ToString、@EqualsAndHashCode、 @RequiredArgsConstructor注解的效果
（2）@Slf4j 注解，添加在类上，给该类创建 Slf4j Logger 静态属性。可以直接使用log.info
（3）@NonNull 注解，添加在方法参数、类属性上，用于 null 参数检查。若确实是 null 时抛出 NullPointerException 异常。

4、springmvc基础：http://www.iocoder.cn/Spring-Boot/SpringMVC/?github
@RestController注解，添加在类上，是@Controller和@ResponseBody 的组合注解，直接返回接口方法的结果，默认情况下使用JSON作为序列化方式。
集成测试+单元测试+全局统一返回（@ControllerAdvice）+全局异常处理+HandlerInterceptor 拦截器+Cors跨域+整合 Fastjson

 

5、SpringSession
在我们部署生产环境下的Tomcat等 Web 容器的时候，一定是需要部署多个节点保障高可用。此时，Session 的一致性就成为一个问题，也就是说相同 sessionid 在多个 Web 容器下，Session 的数据要一致。
解决方案：
（1）Session黏连：
使用 Nginx 实现会话黏连，将同一个浏览器所发起的请求转发到同一台服务器。这样就不会存在多个 Web服务器创建多个 Session 的情况，也就不会发生 Session 不一致的问题。
不过这种方式目前基本不被采用。因为如果一台服务器重启，那么会导致转发到这个服务器上的 Session 全部丢失。
（2）Session 复制。
Web 服务器之间进行 Session 复制同步。这种方式也基本也不被采用。试想一下如果我们有 5 台 Web 服务器，所有的 Session 都要同步到每一个节点上，一个是效率低，一个是浪费内存。
（3）Session 外部化存储。
Session 外部化存储，不再采用 Web 容器的内存中存储 Session ，而是将 Session 存储外部化，持久化到 MySQL、Redis、MongoDB 等数据库中。这样Tomcat 就可以无状态化，专注提供 Web 服务或者 API 接口。如Spring Session
现在，基本绝大多数会话信息，都是希望做到用户级别的共享，那么 Session 的定位就非常尴尬，慢慢的都被拆分到 Redis 缓存中。
在过去，客户端一般来说主要就是浏览器，而现在客户端可以是 PC 浏览器、Mobile 浏览器、微信小程序、iOS 又或者 Android 客户端。而 sessionid 的机制，是将当前客户端和服务端的 Session 会话进行绑定。现在，用户会使用多个客户端，这个是目的非常常见的情况。那么，一个用户在多个客户端，会有多个 sessionid ，和服务端的多个 Session 会话进行绑定。
同时，因为 sessionid 可以和服务端的 Session 会话进行绑定，所以用户在登录之后，sessionid 我们就可以作为用户的身份标识。而现在，OAuth2 和 JWT 慢慢普及开来，大家越来越倾向使用这两者取代 sessionid 。
一般而言，倾向功能强大的 OAuth2 。为什么呢？现在都是长会话，用户登录后，保持 30 天有效。
那么 OAuth2 相比 sessionid 来说，每次请求带的是 accessToken 访问令牌，过期时间是 2 小时，万一泄露也最多是 2 小时。而 sessionid 泄露是“永久”，因为可以不断活跃，刷新会话的过期时间。 当然，机智的胖友可能会问，OAuth2 万一泄露的是 refreshToken 刷新令牌呢？那可能有点危险，不过因为 refreshToken 并不会每次请求都带着，所以泄露的几率会大大降低。
那么 OAuth2 相比 JWT 来说，因为 JWT 是无状态的 Token ，所以无法实现服务端级的严谨的 Token 过期策略。例如说，用户登出 Token 失效，又或者用户修改密码 Token 失效。因此，虽然说 OAuth2 需要引入借助外部存储器来存储状态，但是带来的好处不言而喻。同时，OAuth2 提供了四种认证方式，也为未来的业务拓展提供了更多的可能性

6、WebSocket
WebSocket为浏览器和服务端提供了双工异步通信的功能，即服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，属于服务器推送技术的一种，且能完成实时性较高的需求（HTTP 协议只能由客户端发起）。例如说，聊天 IM 即时通讯功能、消息订阅服务、网页游戏等等。
WebSocket 相比普通的 Socket 来说，仅仅是借助 HTTP 协议完成握手，创建连接。后续的所有通信，都和 HTTP 协议无关。