java面试学习路线图

0~65535

Mysql：3306

Oracle:1521

Tomcat:8080

Web服务器：80

FTP服务器：21

TCP是面向连接的

每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的(一对一)

TCP提供可靠支付的服务，通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达

TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据

面向字节流。TCP中的“流”（stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

UDP是无连接的

UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态

UDP是面向报文的

UDP没有阻塞控制，因此网络出现阻塞不会使源主机的发送速率降低(对实时应用很有用，如IP电话，实时视频会议等)

UDP支持一对一、一对多、多对一和多对多的交互通信

UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短

vim /etc/hosts

修改配置文件

RestTemplate Bean 声明添加 @LoadBalanced

代码实例

修改请求地址

@LoadBalanced 默认采用轮询算法

YML 配置

YML 配置

某一时刻，不会自动删除服务

配置

服务发现

健康检查

KV 存储

多数据中心

可视化WEB管理

安装步骤 ：https://learn.hashicorp.com/consul/getting-started/install

集中式 LB

进程内 LB

配置轮询（默认轮询）

Ribbon + RestTemplate

cn.edu.cqvie.myrule

@RibbonClient(name="PAYMENT-SERVICE", configuration = MySelfRule.class)

@FeignClient

对方服务超时了，调用者不能一直死等，必须有服务降级

对方服务器 down 机了，调用者不能卡死等待，必须有服务降级

对方服务OK， 调用者自己出现故障（自己等待时间小于服务的超时时间，自己要求服务降级）

当满足一定的阈值的到时候（默认10秒内超过20次请求）

当失败率到达一定的时候，默认10秒内超过50%的请求失败

到达以上阈值，断路器将会开启

当开启的时候，所有的请求都不会进行转发

一段时间之后，（默认5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会挂壁，若失败，继续开始重复 4，5

注意依赖

注意新版本 Hystrix 需要在启动类 中指定监控路径

Unable to connect to Command Metric Stream

404

监控配置地址：http://127.0.0.1:8001/hystrix.stream

异常访问：http://127.0.0.1:8001/payment/payInfo/1

正常访问：

1. netflix 不靠谱，zuul2.0 一直跳票，迟迟不发布

2. springcloud gateway 具有如下特征

3. springcloud gateway  和  zuul 的区别

webflux

在配置文件YML 中配置

代码中注入 RouteLoctor 的 Bean

两个主要接口介绍

能做什么

案例代码

测试

config-dev.yml

config-test.yml

config-prod.yml

git add . 

git commit -m 'init yml'

git push

master  分支

dev 分支

http://127.0.0.1:3344/config-dev.yml

http://127.0.0.1:3344/config-test.yml

http://127.0.0.1:3344/config-prod.yml

http://127.0.0.1:3344/config-xx.yml

http://127.0.0.1:3344/config/dev/master

http://127.0.0.1:3344/config/test/master

http://127.0.0.1:3344/config/prod/master

修改 Server-Client 

POM 引入 actuator 监控

修改 YML , 暴露监控端口

@RefeshScope 业务类Controller 修改

此时 修改 GitHub -> Config-Server -> Config-Client

How

再次

RabbitMQ

Kafka

打破了微服务的职责单一性，因为微服务本省是业务模块，它本不应该承担配置刷新的职责

破坏了微服务各个节点的对等性

有一定的局限性，例如, 在微服务迁移时，它的网络地址常常会发生变化，如果此时时想自动属性，会增加更多的工作

修改 GitHub 上的配置

发送POST 请求

http://127.0.0.1:3344/dev/config-dev.yml

http://127.0.0.1:8001/configInfo

只通知 payment-8001

不通知 payment-8002

屏蔽消息中间件的差异，降低切换恒本，统一的消息编程模型

https://github.com/spring-cloud/spring-cloud-stream

https://cloud.spring.io/spring-cloud-static/spring-cloud-stream/3.0.3.RELEASE/reference/html/

中文资料

生产者/消费者之间靠消息媒介传递内容

消息必须走特定的通道

消息通道中的消息如何被消费， 谁来负责收发处理

Stream 为什么可以统一底层的差异

Binder

Topic 主题进行广播

很方便的连接中间件，屏蔽差异

通道，是队列 Queue 的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过channel 队列进行配置

简单的理解为参照对象 Spring Cloud  Stream 自身，
从 Steam 发布消息就是输出，接受消息就是输入

中间件，目前只支持 RabbitMQ 和 Kafka

Binder  是应用消息中间件之间的封装， 目前实现了 Kafka 和 RabbitMQ 的Binder 
通过 Binder 可以很方便的连接中间件，可以动态的改变消息类型（对于 Kafka 的 topic , rabbitmQ 的 exchange）, 
这些都可以通过配置文件来实现。

注解标识输入通道，通过该输入通道接收到的消息进入应用程序

注解标识输入通道，发布的消息将通过通道离开应用程序

监听队列，用于消费者的队列的消息接受

指信道 channel 和 exchange 绑定在一起。

curl http://127.0.0.1:8701/rabbit/send

如何解决

生产实际问题

故障现象是重复消费

导致现象是默认分组是不同的，组流水号不同，可以消费

自定义配置分组， 自定义配置分为同一个组，解决

重复消费问题

微服务应用放置于同一个group 中， 就能保证消息只会被其中一个应用消费一次
不停的小组是可以消费的，同一个组内会发生竞争关系，只有其中一个可以消费

group: atcqvie-01, atcqvie-02

消费者-1 修改 YML

消费者-2 修改 YML

自己的配置

结论

group: atcqvie-01

消费者-1 修改 YML

消费者-2 修改 YML

消费者-1 的 group: atcqvie-01 没有去掉

Spring Cloud 从 F 版本过后已经不需要自己构建 Zipkin Server 了，只需要调用jar 即可

https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/

zipkin-server-2.12.9-exec.jar

java -jar zipkin-server-2.12.9-exec.jar

访问控制台：http://localhost:9411/zipkin/

术语

https://github.com/alibaba/spring-cloud-alibaba

https://github.com/alibaba/spring-cloud-alibaba/tree/greenwich

https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

等价于

https://nacos.io/en-us/

https://spring-cloud-alibaba-group.github.io/github-pages/greenwich/spring-cloud-alibaba.html

注册到 nacos

curl http://127.0.0.1:9002/payment/nacos/2

启动 nacos

启动 payment-service、order-service

curl http://127.0.0.1:9101/consumer/payment/nacos/1

Nacos 全景图所示

Nacos 和 CAP

切换

bootstrap.yml

application.yml

Nacos 中的匹配规则

curl http://127.0.0.1:9001/config/info

启动配置信息

修改下  Nacos 中的yaml 配置文件，再次调用查看配置的接口，就会发现配置已经刷新

多环境多项目管理

配置空间

命名空间

三种方案加载配合

持久化

官网说明

https://github.com/alibaba/nacos/blob/develop/config/pom.xml

nacos-server-version\nacos\conf 目录下找到 sql 脚本

nacos-server-version\nacos\conf 目录下找到  application.properties

https://github.com/alibaba/nacos/releases/tag/1.2.0

nacos-server-1.2.0.tar.gz

解压后安装

1. Linunx 服务器上 mysql 数据库配置

2. apolication.properties 配置

3. Linux 服务器上 nacos 集群配置 cluster.conf

4. 编辑Nacos 的启动脚本straup.sh, 使它能够接受不同的启动端口

5. Nginx 的配置，由它作为负载均衡器

6. 截止到此处， 1 个 Nginx + 3个nacos 注册中心 + 1个 mysql

微服务 启动注册进入 nacos 集群

查看服务注册情况

实现服务之间的相互调用

https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

https://github.com/alibaba/Sentinel/releases

下载到本地： sentinel-dashboard-1.7.1.jar

前提

命令

http://127.0.0.1:8080

登录账号密码均为: sentinel

界面

服务访问

效果

直接 -> 快速失败

配置说明

测试

关联是什么

配置 A 

postman 模式并发密集访问 testB

运行后发现testA 挂了

多个请求调用同一个微服务

自己试试

直接失败，抛出异常

源码

说明

官网

源码

WarmUp  配置

多次点击 http://localhost:9001/testB

应用场景

设置

设置效果

官网

源码

测试

半开的状态系统自动去检测是否请求有异常，
没有异常就关闭断路器恢复使用，
有异常则继续打开断路器不可用。具体可以参考 Hystrix

复习 Hystrix

是什么

代码

jemter 压测

结论

是什么 

代码

配置

jemter 测试

总结

是什么

异常数是按照分钟统计的

测试

配置

curl http://127.0.0.1:9001/testHotKey\?p1\=1

➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- deal_testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey%    

配置

http://127.0.0.1:9001/testHotKey?p1=1

http://127.0.0.1:9001/testHotKey?p1=1&p2=2

http://127.0.0.1:9001/testHotKey?p2=2

普通

我们期望P1参数当它是某个特殊值时， 他的限流值和平时不一样

特例

子主题

http://127.0.0.1:9001/testHotKey\?p1\=5

https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81

POM

YML

业务 RateLimitController

主启动类

配置步骤

图形配置和代码关系

表示1秒钟内查询次数大于1 ，就跑到我们自定义的限流

1秒钟点击1下，OK

超过上述，疯狂点击，返回了自定义的限流信息，限流发生

关闭服务试试

Sentinel 控制台，流控规则消失了？？？

http://127.0.0.1:9001/byResource

配置

http://127.0.0.1:9001/byResource

结果

CustomerBlockHandler 

http://127.0.0.1:9001/rateLimit/customerBlockHandler

SphU 自定义资源

Tracer 定义统计

ContextUtil 定义了上下文

POM

YML

主启动类

业务类

测试地址

POM 

YML

主启动类

业务类

消费侧提供者  9001/9002

Feign 组件一般是消费侧

带 @FeignClient 注解的业务接口

fallback = PaymentFallbackService.class

Controller

http://127.0.0.1:9101/paymentSQL/1

处理参考

处理方案

添加Nacos 数据源配置

内容解析

默认无法加载流控规则

多次调用

重新配置出现，持久化验证通过

分布式事务处理过程的一个ID + 三个组件模型

SEATA 的分布式交易解决方案

service 模块

store 模块

完整文件

mkdir -p logs

Nacos配置

OrderDao

resources 文件夹下面 创建文件夹 mapper

OrderService

AccountService

StorageService

当库存和账户金额扣减后，订单状态并没有设置为已经完成，没有从零改为1

而且由于feign 的重试机制，账户余额还有可能被多次扣减

《分布式系统管理与规范》定义：
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”，
分布式系统（distributed system）是建立在网络上的软件系统

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已经无法应对，
分布式服务架构以及流动计算架构势在必行，需一个治理系统确保架构有一条不絮的演进。

演变过程

提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

支持多种注册中心服务，服务实例上下线实时感知。

遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。

内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，
适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

http://zookeeper.apache.org/

解压

创建配置文件

运行 

https://github.com/apache/dubbo-admin

mvn clean install

java -Dserver.port=8081 -jar dubbo-admin-server-0.2.0.jar

http://127.0.0.1:8081

准备工作

启动服务发布端（dubbo-provider）

启动服务消费者（dubbo-consumer）

查看服务生产者/消费者

http://dubbo.apache.org/zh-cn/docs/user/best-practice.html

-Ddubbo.registry.address=zookeeper://127.0.0.1:2181

dubbo.registry.address=zookeeper://127.0.0.1:2181

RegistryConfig.setAddress("zookeeper://127.0.0.1:2181")

dubbo.registry.address=zookeeper://127.0.0.1:2181

dubbo.reference.com.foo.BarService.check=false
dubbo.reference.check=false

dubbo.consumer.check=false

dubbo.registry.check=false

查询/修改/删除，不管查询多少次都是幂等的。

数据库新增，比如超时了，就不能是幂等的。

声明服务 1.0.0

声明服务 2.0.0

@EnableDubbo

dubbo.scan.base-packages=cn.edu.cqvie

@org.apache.dubbo.config.annotation.Service(version = "1.0.0")
public class UserServiceImpl implements UserService {
    // other code
}

@Reference(version = "1.0.0")
private UserService userService;

provider.xml 示例

consumer.xml 示例

配置文件

指定Spring扫描路径

健壮性

监控中心宕机不影响使用，只是丢失部分采样数据

数据库宕机后，注册中心仍然能通过缓冲提供服务列表查询，但不能注册新服务

注册中心对等集群，任意一台宕机后，将自动切换到另一台

注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通讯

服务提供者无状态，任意一台宕掉后，不影响使用

服务提供者全部宕掉， 服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

@Reference(version = "1.0.0", url ="dubbo://192.168.1.4:20881")

当服务器压力剧增的情况下，根据实际业务情况以及流量，对一些服务和页面有策略的不处理
或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

可以通过服务降级功能 [1] 临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。

向注册中心写入动态配置覆盖规则：

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
其中：

mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

Failover Cluster

Failfast Cluster

Failsafe Cluster

Failback Cluster

Forking Cluster

Broadcast Cluster

RPC 原理

Netty 原理

创建代理类proxy实现Invocation接口，重写invoke()方法

将被代理类作为构造函数的参数传入代理类proxy

调用Proxy.newProxyInsatnce(classloader,interfaces,handler)方法生成代理类

总结： 代理类调用自己方法时，通过自身持有的中介类对象来调用中介类对象的invoke方法，从而达到代理执行被代理对象的方法。

如果要代理一个接口的多个实现的话需要定义不同的代理类

代理类 和 被代理类 必须实现同样的接口，万一接口有变动，代理、被代理类都得修改,难以维护

1.6和1.7的时候，CGLib更快

1.8的时候，jdk更快

@Configuration 作用于类上，相当于一个xml配置文件；

@Bean 作用于方法上，相当于xml配置中的<bean>；

实现方式

能够在编译时就发现错误

<bean id="text" class="com.maven.Text" />
<bean id="hello" class="com.maven.Hello"><constructor-arg ref="text" /></bean>

构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参数代表一个对其他类的依赖。

使用构造器注入的好处

例如：<bean id="hello" class="com.maven.Hello"><property name="text" ref="text" /></bean>

之所以叫setter方法注入，因为这是通过找到类的对应的setter方法，再进行相应的注入

Setter方法注入是容器通过调用无参构造器或无参static工厂方法实例化bean之后，调用该bean的setter方法，即实现了基于setter的依赖注入。

因为加入singletonFactories三级缓存的前提是执行了构造器(因为要先构建出对象)，所以构造器的循环依赖没法解决。

因为Spring容器不缓存"prototype"作用域的bean，因此无法提前暴露一个创建中的bean。 

通过三级缓存解决

在createBeanInstance()之后会调用addSingleton()方法将bean注册到singletonFactories中

通过提前暴露一个单例工厂方法，从而使其他bean能够引用到该bean/提前暴露一个正在创建中的bean

举例

BeanNameAware

BeanFactoryAware

ApplicationContextAware

调用postProcessBeforeInitialization(Object obj, String s)方法

由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；

调用postProcessAfterInitialization(Object obj, String s)方法

Spring IoC容器中只会存在一个共享的Bean实例，无论有多少个Bean引用它，始终指向同一对象。

singleton是Bean的默认作用域

默认情况下是容器初始化的时候创建，但也可设定运行时再初始化bean

DefaultSingletonBeanRegistry类里的singletonObjects哈希表保存了单例对象。

每次通过Spring容器获取prototype定义的bean时，容器都将创建一个新的Bean实例，每个Bean实例都有自己的属性和状态

当容器创建了bean的实例后，bean的实例就交给了客户端的代码管理，Spring容器将不再跟踪其生命周期,并且不会管理那些被配置成prototype作用域的bean的生命周期。

对有状态的bean使用prototype作用域，而对无状态的bean使用singleton作用域。

在一次Http请求中，容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效。

在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。

在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在使用portlet context时有效。

创建bean

找到@Autowired的对象

创建注入对象，并赋值

新的 leader 与 follower 建立先进先出的队列， 先将自身有而 follower 没有的 proposal 发送给 follower，再将这些 proposal 的 COMMIT 命令发送给 follower，以保证所有的 follower 都保存了所有的 proposal、所有的 follower 都处理了所有的消息 

minor GC(将剩余存活对象移动到survivor区)

From区

To区

JVM怎么保证线程安全

保证实例的唯一性

额外存储每次对某条聚簇索引记录进行修改的事务id和指向这条聚簇索引上一个版本的位置，上一版本的数据会保存在Undo日志中

ReadView中有个列表存储系统中未提交的事务，通过这个列表来判断记录的某个版本是否对当前事务可见

读锁(共享锁)

写锁(排他锁)

lock table表名称 read(write)
unlock tables

例如：select * from xx for update

在select语句后面加了 for update 相当于加了排他锁,加了写锁以后，其他的事务就不能对它修改了，需要等待当前事务修改完之后

lpush key value1 [value2....]

rpush key value1 [value2....]

lpop key

rpop key

count > 0

count < 0

count = 0

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求

BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求

服务器在执行完一个写命令之后，以协议格式将被执行的命令追加到aof_buf缓冲区的末尾中

随后会调用flushAppendOnlyFile函数考虑是否需要将aof_buf缓冲区的内容写入到AOF文件中

最后确定是否将AOF文件内容同步

对CPU时间来说是最友好的：程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何CPU时间

对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放