java中的关键词汇含义和细碎知识点

一： java

https://blog.csdn.net/sinat_35512245/article/details/59056120
记录java项目中的关键词汇

1.1 HandleInterceptor拦截器

SpringMVC的处理器拦截器，类似于Servlet开发中的过滤器Filter，用于对请求进行拦截和处理。

• preHandle：在业务处理器处理请求之前被调用。预处理，可以进行编码、安全控制、权限校验等处理；
• postHandle：在业务处理器处理请求执行完成后，生成视图之前执行。后处理（调用了Service并返回
• ModelAndView，但未进行页面渲染），有机会修改ModelAndView （这个博主就基本不怎么用了）；
  afterCompletion：在DispatcherServlet完全处理完请求后被调用，可用于清理资源等。返回处理（已经渲染

单个实现类的执行顺序
preHandler -> Controller -> postHandler -> model渲染-> afterCompletion

1.2 instanceof

用来在运行时指出对象是否是特定类的一个实例，返回布尔类型

if (anObject instanceof String){
   

}else{
   

}

1.3 分布式跟踪技术

1.3.1 Dapper

• Dapper：大规模分布式系统的跟踪系统，帮助理解系统行为，用于分析性能问题，

1.3.2 Sleuth框架

用于跟踪服务的调用过程
Sleuth借鉴了Google Dapper的设计，先了解两个概念

• Trace 表示整个跟踪过程，从用户发起请求到最终的响应。一次跟踪包括多个跨度，这些跨度以树状结构进行保存。
• Span：跨度，表示一次调用的过程，一次跟踪包含多次调用过程。假设用户向A服务发起请求，A服务又要调用B服务，那么此时将会产生两个跨度。用户调用A服务、A服务调用B服务。

1.3.3 RPC

• RPC(Remote Procedure Call Protocol)–远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议
• RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。

1.3.4 Zipkin

• Zipkin是一个分布式跟踪系统，主要用于收集、管理微服务产生的数据。Zipkin的设计基于Google Dapper，在实际用时，我们需要让各个微服务Zipkin服务器报告过程数据。
• 对于Spring Cloud来说，已经提供了几个模块来实现数据报告功能，仅需要加入依赖，以及简单配置，即可实现向Zipkin“写入”数据

1.4 Thymeleaf

• Thymeleaf是一个流行的模板引擎,
• 页面模板技术
• Thymeleaf的主要目标在于提供一种可被浏览器正确显示的、格式良好的模板创建方式，因此也可以用作静态建模。你可以使用它创建经过验证的XML与HTML模板

传统的Spring WEB技术，使用JSP页面技术，spring boot 已不推荐，spring boot 支持以下页面模板语言

• Thymeleaf
• FreeMarker
• Velocity
• Groovy
• JSP

1.4 安全幂等

get：安全幂等
post：不安全不幂等：当插入一条数据时，遇到网络不佳，可能会多插入，所以不幂等
update：多次更新，扔一个条数据，所以幂等
幂等：对数据库操作成功之后会不会产生影响，如果有影响则是不幂等
Post

1.5 snowflake (雪花)算法

• 用于生成不同的ID，总共64位。

1.6 JPA

类似与mybatis

1.7 RESTful API

1.7.1 介绍

• RESTful API就是一套协议来规范多种形式的前端和同一个后台的交互方式。
• RESTful API由后台也就是SERVER来提供前端来调用。前端调用API向后台发起HTTP请求，后台响应请求将处理结果反馈给前端。也就是说RESTful 是典型的基于HTTP的协议

1.7.2 设计原则和规范

• 资源：资源就是网络上的一个实体，一段文本，一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。文本可以用TXT，也可以用HTML或者XML、图片可以用JPG格式或者PNG格式，JSON是现在最常用的资源表现形式。
• 统一接口：RESTful风格的数据元操CRUD（create,read,update,delete）分别对应HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口。
• URL：可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI就是URL。
• 无状态：所谓无状态即所有的资源都可以URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而变化。

二：注解

2.1 @Component

泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标记

2.2 @CrossOrigin

在微服务中，在controller层加上该注解，允许跨域请求

2.3@ConfigurationProperties和@EnableConfigurationProperties

• @ConfigurationProperties注解主要用老吧properties配置文件转换为bean使用，
• @EnableConfigurationProperties作用是为了让ConfigurationProperties注解生效，如果只使用前者，则无法将配置文件装成bean。

三：理论

3.1 CAP理论

CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• 一致性：即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，所以，一致性，说的就是数据一致性。
• 可用性：服务一直可用，而且是正常响应时间。对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。
• 分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。
  

假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1，由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧