我的随笔4

80.http 协议的状态码

1xx：指示信息—表示请求已接收，继续处理2xx：成功—表示请求已被成功接收、理解、接受3xx：重定向（要完成请求，需要进一步的操作）
4xx：客户端错误（请求有语法错误或请求无法实现）5xx：服务器错误（服务器在处理请求时发生内部错误）如： 400：客户端请求有语法错误，不能被服务器所理解
404：请求资源不存在
403：服务器收到请求，但是拒绝提供服务500：服务器发生不可预期的错误

81.当浏览器发出 www.baidu.com 的执行流程

浏览器获取输入的域名 www.baidu.com
再向域名系统 DNS 请求解析该域名的 IP 地址DNS 解析出百度服务器的 IP 地址
浏览器与服务器建立 TCP 连接（默认端口 80）
浏览器发出 HTTP 请求，请求百度首页
服务器响应 HTTP 请求，把首页文件发给浏览器
TCP 连接释放
浏览器解析首页文件，展示 web 界面

82.http 解析的全过程

域名解析 --> 发起TCP 的3 次握手，建立TCP 连接 -->浏览器发起http 请求 --> 服务器响应 http 请求，浏览器得到 html 代码 --> 浏览器解析 html 代码，并请求 html 代码中的资源（如 js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

83.http 和 https 的区别？

http 是明文传输，https 是加密传输
http 是简单、无状态的，https 是 ssl+http 构建的可进行加密传输、身份认证的网络协议
http 端口是 80，https 端口是 443
http 证书免费申请，https 需要到 ca 申请证书，一般免费证书很少，需要交费。http 的不足：通信内容使用明文——内容可能被窃听
不验证通信方的身份——可能遭遇伪装
无法验证报文的完整性——报文有可能已遭篡改

84.什么是 Socket？

网络中的不同计算机通信就得使用网络套接字（socket），它就是在不同计算机之间进
行网络通信的一个抽象，它工作于 tcp/ip 协议中应用层和传输层之间的一个抽象

85.osi 网络七层协议

OSI 模型有 7 层结构，每层都可以有几个子层。 OSI 的 7 层从上到下分别是
7 应用层：网络服务与最终用户的一个接口。
6 表示层：负责数据格式的转换，确保一个系统的应用层信息可被另一个系统应用层读
取（设备固有数据格式以及网络标准数据格式的转换）
5 会话层：建立和管理应用程序之间的通信（何时建立、断开连接以及保持多久的连接）
4 传输层：监控数据传输服务的质量，保证报文的正确传输。（是否又数据丢失）
3 网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。
2 数据链路层 ：负责物理层面上的互联、节点间的通信传输，并封装成帧（数据帧和比特流之间的转换）

1 物理层 ：进行比特流和电子信号间的切换
其中高层（即 7、6、5、4 层）定义了应用程序的功能，下面 3 层（即 3、2、1 层）主要面向通过网络的端到端、点到点的数据流。

86.单片，SOA 和微服务架构有什么区别（理论层面）？

单片架构类似于大容器，其中应用程序的所有软件组件组装在一起并紧密封装。
SOA 面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为
服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
微服务架构是一种结构风格，是在 SOA 上做的升华，它强调的一个重点是“业务需要彻底的组件化和服务化”， 它将单一应用程序划分成一组小的服务。每个服务运行在其独立的自己的进程中，这些服务之间互相协调、互相配合，为用户提供最终价值

87.微服务和单体架构区别（具体层面）

1、单体架构所有的模块全都耦合在一块，而微服务每个模块就相当于一个单独的项目
（模块耦合）
2、单体架构所有的模块都共用一个数据库，微服务每个模块都可以使用不同的存储方
式（数据库层面）
3、单体架构所有的模块开发所使用的技术一样。微服务每个模块都可以使用不同的开发技术（技术层面）

88.微服务架构的优缺点

优点：服务解耦、独立的开发、部署环境、更高的扩展性、简化配置
缺点：它是分布式系统，相较于单体架构，它有一定的复杂性，服务更多，维护起来相
对也会比较困难

89.SpringBoot 常用注解

a) @PathVariable 可以将 URL 中占位符参数绑定到控制器处理方法的入参中：URL
中的 {xxx} 占位符可以通过；
b) @RequestBody 可以直接将页面中的参数封装成实体类中的数据传输给后台；
c) @Controller 表示这是一个控制器
d) @RequestMapping：处理请求地址的映射

90.什么是 spring，什么是 SpringBoot？

Spring 是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器 框架。

Spring Boot 是一种全新的编程规范，其设计目的是用来简化 Spring 应用初始搭建以及开发过程。它使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot 其实就是一个整合很多可插拔的组件（框架），内嵌了使用工具（比如内嵌了Tomcat、Jetty 等），方便开发人员快速搭建和开发的一个框架。。

91.spring 与 SpringBoot 的联系

1、Springboot 将原有的 xml 配置，简化为了 java 注解
2、使用 idea 可以很方便的搭建一个 springboot 项目，选择对应的 maven 依赖，简化
spring 应用的初始搭建以及开发过程
3、Springboot 有内置的tomcat 服务器，可以jar 形式启动一个服务，可以快速部署发布web 服务
4、springboot 使用 starter 依赖自动完成 bean 配置，解决 bean 之间的冲突，并引入相关的 jar 包

92.SpringBoot 自动配置原理

SpringBoot 启动的时候会去解析启动类上的@SpringBootApplication 注解，而这个注解是个复合注解，它里面有一个 @EnableAutoConfiguration 注解用来开启自动配置，这个注解它主要利用了一个@import 注解引入了一个（AutoConfigurationImportSelector.class）类，这个类有一些核心方法，会去扫描我们 jar 包下的 META-INF 下的 spring.factories 文件，这个文件记录了很多的自动配置类，然后将这些配置类加载到容器中，然后根据这些配置类中的条件注解，来判断是否将这些配置类在容器中进行实例化，这些条件主要是判断项目是否有相关 jar 包或是引入了相关的 bean，这样 SpringBoot 就可以帮我们完成自动装配

93.请谈谈你对 SpringBoot 和 SpringCloud 的理解

SpringBoot 专注于快速方便的开发单个个体微服务。
SpringCloud 则是关注全局微服务的协调和整理，，为各个微服务之间提供服务注册发
现、熔断器，配置中心等集成服务
SpringBoot 可以离开 SpringCloud 独立使用开发项目，但是 SpringCloud 离不开

SpringBoot，属于依赖的关系.

94.SpringCloud 中 Eureka 与 zookeeper 的区别

在分布式领域有一个很著名的 CAP 定理：C 数据一致性、A 服务可用性、 P 分区容错性， 在这些特性中任何分布式系统只能保证同时满足两个特性，而由于当前网络延迟故障会导致丢包的问题，所以我们的分区容错性是必须实现的，我们只能在 C 和 A 中进行选择，
而 Eureka 在 CAP 定理中保证的是 AP，Zookeeper 则是 CP
因此、Eureka 可用很好的应对因网络故障导致部分节点失去联系的情况，只不过不保
证强一致性，而不会想 zookeeper 那样使整个注册服务瘫痪

95.Eureka 是如何保证 AP 特性的

Eureka Server 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

96.分布式系统的 CAP 原理

CAP 定理指的是在一个分布式系统中，Consistency [kənˈsɪstənsi]（一致性）、Availability [əˌveləˈbɪlətɪ]（可用性）、Partition tolerance（分区容错性），三者不可同时获得。
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节
点在同一时间的数据完全一致，越多节点，数据同步越耗时）
可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）
分区容错性（P）：分区容错性，就是高可用性，一个节点崩了，并不影响其它的节点
（100 个节点，挂了几个，不影响服务，越多机器越好）CA 满足的情况下，P 不能满足的原因：
数据同步©需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以 P 就不满足
CP 满足的情况下，A 不能满足的原因：
数据同步保持一致性©需要时间, 机器数量也多§，所以不能在正常时间内响应，
所以 A 就不满足
AP 满足的情况下，C 不能满足的原因：
机器数量也多§，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以 C 不满足

97.springCloud 组件、

服务发现——Netflix ['netfliːks] Eureka [juˈrikə] （Nacos）
服务调用——Netflix Feign [feɪn]
熔断器——Netflix Hystrix [hɪst’rɪks]
服务网关——Spring Cloud GateWay [ˈɡeɪtˌweɪ] 替代 zool配置中心——Spring Cloud Config （Nacos）
消息总线 —— Spring Cloud Bus [bəs] （Nacos）

98.Mybatis Plus 相比 Mybatis 有什么优势？

Mybatis-Plus 是一个 Mybatis 的增强工具，它在 Mybatis 的基础上做了增强，却不做改变。Mybatis-Plus 是为简化开发、提高开发效率而生，但它也提供了一些很有意思的插件，比如分页、性能分析、代码生成器等。

99.说出几个 Mybatis Plus 的常用注解？

有以下几个常用注解@TableName：对数据表名注解；@TableId：表主键标识；@TableField：表字段标识；@Version：乐观锁注解、标记；
@TableLogic：表字段逻辑处理注解（逻辑删除）；

100. Mybatis Plus 插入语句之后如何返回主键？

数据的主键 id 值，可以直接在插入后通过 Integer id = 实体类 getId()获取。

101. Mybatis Plus 的逻辑删除怎么实现？

给表增加deleted 字段，用于表示数据是否被删除，可以定义：1 代表删除，0 代表未删除。同时，也修改实体，增加 deleted 属性并且添加@TableLogic 注解：
在 application.properties 中配置（基于 springboot）:逻辑已删除值(默认为 1)
mybatis-plus.global-config.db-config.logic-delete-value=1
逻辑未删除值(默认为 0) mybatis-plus.global-config.db-config.logic-not-delete-value=0

102. 怎样用 Mybatis Plus 实现表主键自增？

@TableId(type=IdType.AUTO)

103. 什么是断言

断言：也就是所谓的 assertion，是 jdk1.4 后加入的新功能。
它主要使用在代码开发和测试时期，用于对某些关键数据的判断，如果这个关键数据不是你程序所预期的数据，程序就提出警告或退出。
static int i = 5;
public static void main(String[] args) {
assert i==6; //这里结果为 false，则不往下执行，抛出异常
System.out.println(“如果断言正常，我就被打印”);
}
用法二：
case 5: System.out.println(“正常”); break;
default:

assert false:“i 的值无效”; //如果 i 的值不是你想要的，程序就警告退出

}

104. 什么是

js 的闭包

由于在 Javascript 语言中，只有函数内部的子函数才能读取局部变量，因此可以把闭包简单理解成"定义在一个函数内部的函数"。
所以，在本质上，闭包就是将函数内部和函数外部连接起来的一座桥梁。

105. String s = new String(“xyz”);创建了几个字符串对象？

两个对象，一个是静态区的"xyz"，一个是用 new 创建在堆上的对象。

106. 消息队列

消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。
我们可以把消息队列比作是一个存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性
在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因

此响应速度得到大幅改善。
消息队列带来的问题：
系统可用性降低： 系统可用性在某种程度上降低，为什么这样说呢？在加入 MQ 之前，你不用考虑消息丢失或者说 MQ 挂掉等等的情况，但是，引入 MQ 之后你就需要去考虑了！
系统复杂性提高： 加入 MQ 之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！
一致性问题： 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!
当前：学到 kafka 有解决，有空可以去复习复习 kafka 与 Streaming 直连处理

107. 面向对象的特征

继承：就是保留父类的属性，开扩新的东西。子类通过继承可以使用父类的状态和行为，同时添加自身的状态和行为。
封装：就是类的私有化。将代码及处理数据绑定在一起的一种编程机制，该机制保证程序和数据不受外部干扰。
多态：允许将子类类型的指针赋值给父类类型的指针。包括重载和重写。重载为编
译时多态，重写是运行时多态。
抽象： 抽象是把多个事物的共性的内容抽取出来。

108. 高并发

高并发的处理分为以下六点：系统拆分、缓存、MQ、分库分表、读写分离、
ElasticSearch
系统拆分：将一个系统拆分为多个子系统，用 dubbo 来搞，然后每个系统连一个数据
库，这样本来就一个库承担的压力，现在可用由多个库分担这个压力了
缓存：大多数的高并发场景都是读多写少，那你完全可用在数据库和缓存里都写一
份，然后读的时候大量走缓存不久得了，毕竟 redis 可用轻轻松松单机几万的并发
MQ：将大量的请求灌入 MQ 里，排队慢慢玩儿，后边系统消费慢慢写，控制在 mysqk承载的范围内
分库分表：将数据库拆分为多个库，多个库来抗更高的并发！还有将一个表拆分为多
个表，每个表的数量保持少一点，提高 sql 跑的性能
读写分离：大部分数据库可能是读多写少，没必要将所有请求都集中在一个库上，可用搞个主从架构，主库写入，从库读取，搞个读写分离，读流量太多的时候，还可用添加更多的从库
ElasticSearch：简称 es，es 是分布式的，可用随便扩容，分布式天然就可用支撑高并发，因为动不动就可以扩容机器来扛更高的并发

109. 什么是 MVC

MVC 是 model-view-controler 的简称。也就是模型-视图-控制器。
他强制性的把应用程序的输入、处理和输出分开。他们分别担任着不同的任务。
模型(Model):负责数据逻辑的处理和实现数据库操作，JavaBean视图(View):负责格式化数据并把他们呈现给用户，JSP 和 Html
控制器(Controller):负责接收并转发请求，将请求处理后指派视图并将结果发送给
客户端

110. 你的两个项目怎么没有关联？你公司是做什么的？

我上家公司一个高新技术企业的信息技术公司，客户涵盖教育、银行、保险等领域
就是外包呗？ 其实外包它分为人力外包和项目外包，而我们公司做的就是项目外包，是整个项目都是我们负责，是我们公司和其他公司参与竞标获得的项目，如果只是人力外包，学不到什么东西，那么我做不了这么久

111. 分库分表、读写分离和主备切换分别是如何实现的？

// TODO

112. 子类 A 继承父类 B，创建后他们的执行的先后顺序

是？

父类Ｂ静态代码块->子类Ａ静态代码块->父类Ｂ非静态代码块->父类Ｂ构造函数->子类Ａ非静态代码块->子类Ａ构造函数