SpringBoot课程笔记
黑马程序员SpringBoot2课程笔记
一、基础篇
略
二、运维实用篇
1.SpringBoot运行与部署
略
2. SpringBoot配置
2.1 临时属性配置
可以在启动Boot程序时添加临时属性改变配置
2.1.1 属性加载优先级
配置是属性是存在优先级的，当项目中的配置冲突时，优先级高的配置会覆盖优先级低的配置
具体的优先级关系如下：
2.1.2 开发环境使用临时属性
在开发环境中也可以添加临时属性改变配置
临时属性会作为启动类的形参传入启动方法，为防止程序被临时属性破坏，可以通过去掉启动类的形参提高我们程序的安全性
2.1.3 小结
2.2 配置文件分类
在实际开发中，各级开发及管理人员应操作不同的配置文件，
SpringBoot中有4级配置文件，如下：
不同级别的配置文件间配置互补，冲突的配置按优先级生效
2.3 自定义配置文件
SpringBoot启动时默认加载名称为Application的配置文件，可以通过设置启动参数更换加载的配置文件名称
此处加载名称为ebank的配置文件
3. 多环境开发
在企业中不同的开发环境对应不同的配置
3.1 单yaml文件配置
可以在一个yaml配置文件中设定不同环境对应的配置，不同的环境配置用---分割
设置active属性，指定启用的环境配置
格式如下：
3.2 多yaml文件配置
使用单一yaml文件配置多环境有暴露权限的风险，不利于维护。
所以使用多个配置文件对应不同的生产环境更加合理。
3.3 多properties文件配置
properties文件配置多环境只支持多文件配置
3.4 多环境配置文件拆分
将不同技术的配置文件拆分来开，在主配置文件中引入，利于维护管理
注意引入配置文件时，配置文件的加载顺序会影响配置的生效，主配置文件必定最后一个加载
SpringBoot2.4后的多环境配置方式：
3.5 多环境开发控制
Maven和SpringBoot都存在多环境的配置管理，而SpringBoot程序依赖于Maven，所以在实际开发时应以Maven的多环境配置为准，让SpringBoot读取Maven的配置
实现步骤：
步骤①：在Maven中进行多环境配置，每个配置内设定对应的属性变量
步骤②：在Boot配置文件中使用@...@占位符，读取当前生效的Maven属性值
步骤③：执行打包操作
4. 日志
4.1 日志基础配置
4.2 快速创建日志对象
4.3 日志输出格式控制
SpringBoot默认日志格式：
自定义日志格式：
4.4 日志文件
在实际开发中，日志信息应输出到文件中以便项目的维护
三、开发实用篇
1. 热部署*
热部署指当我们对项目进行修改后，无需重启服务器即可让修改生效
1.1 手动开启热部署
步骤如下：
重启和重载的概念：
因为热部署不需要重新加载jar包，所以热部署只执行重启操作，而重启项目会执行重启和重载操作。
1.2 自动开启热部署
手动开启热部署每次都要手动的去Build工程，繁琐程度与重启项目比并无太大差别，可以通过设置让IDEA自动Build工程
步骤如下：
第①步：在设置中勾选自动构建项目开关
第②步：快捷键ctrl + alt + shift + /打开菜单，勾选自动构建
设置完成，当修改完项目代码之后，只需离开IDEA5秒后即可激活热部署
1.3 参与热部署监控的文件范围配置
通过修改项目中的文件，可以发现其实并不是所有的文件修改都会激活热部署的，原因在于在开发者工具中有一组配置，当满足了配置中的条件后，才会启动热部署
配置中默认不参与热部署的目录信息如下：
可以在Applicaiton.yml配置文件中自定义哪些文件/文件夹不参与热部署
1.4 关闭热部署
方式①：修改Application.yml配置文件
将enabled属性改为flase
注意：配置文件存在优先级，有可能在更高级别的配置文件中设置了开启热部署，覆盖了此处的设置
方式②：使用更高级别的配置关闭热部署
既然我们怕别人在优先级别高的地方启动热部署，那我们就在优先级别比较高的地方禁用热部署
配置的优先级如下：
application.yml配置文件在优先级为3的地方，我们可以在其更高的优先级位置关闭热部署
在启动类中设置系统属性（级别6）关闭热部署
在springboot启动类当中输出 System.setProperty("spring.devtools.restart.enabled","false");即可关闭热部署功能
2. 配置高级
2.1 第三方bean属性绑定(注入)
在基础篇学习了@ConfigurationProperties注解，此注解的作用是用来为bean绑定(注入)属性的。
回顾一下使用过程，开发者可以在yml配置文件中以对象的格式添加若干属性
servers:
ip-address: 192.168.0.1
port: 2345
timeout: -1然后再定义一个用来封装数据的实体类，注意要提供属性对应的setter方法，
@Component
@Data
public class ServerConfig {
private String ipAddress;
private int port;
private long timeout;
}最后使用@ConfigurationProperties注解就可以将配置中的属性值注入到开发的模型类上。
@Component
@Data
@ConfigurationProperties(prefix = "servers")
public class ServerConfig {
private String ipAddress;
private int port;
private long timeout;
}这样加载对应bean的时候就可以直接加载配置属性值了。但是目前我们学的都是给自定义的bean使用这种形式加载属性值，如果是第三方的bean呢？能不能用这种形式加载属性值呢？为什么会提出这个疑问？原因就在于当前@ConfigurationProperties注解是写在类定义的上方，而第三方开发的bean源代码不是你自己书写的，你也不可能到源代码中去添加@ConfigurationProperties注解，这种问题该怎么解决呢？下面就来说说这个问题。
使用@ConfigurationProperties注解其实可以为第三方bean加载属性，格式特殊一点而已，以Druid数据源为例：
步骤①：使用@Bean注解定义第三方bean
@Bean
public DruidDataSource datasource(){
DruidDataSourceds=newDruidDataSource();
returnds;
}步骤②：在yml中定义要绑定的属性，注意datasource此时全小写
datasource:
driverClassName: com.mysql.jdbc.Driver步骤③：使用@ConfigurationProperties注解为第三方bean进行属性绑定，注意前缀是全小写的datasource
@Bean
@ConfigurationProperties(prefix="datasource")
publicDruidDataSourcedatasource(){
DruidDataSourceds=newDruidDataSource();
returnds;
}操作方式完全一样，只不过@ConfigurationProperties注解不仅能添加到类上，还可以添加到方法上，添加到类上是为spring容器管理的当前类的对象绑定属性，添加到方法上是为spring容器管理的当前方法的返回值对象绑定属性，其实本质上都一样。
做到这其实就出现了一个新的问题，目前我们定义bean不是通过类注解定义就是通过@Bean定义，使用@ConfigurationProperties注解可以为bean进行属性绑定，因为这个注解不仅可以写在类上，还可以写在方法上，所以无法直观的查看到有哪些bean通过注解@ConfigurationProperties去绑定了属性，不利于开发与维护。
为了解决这个问题，spring给提供了一个全新的注解@EnableConfigurationProperties，专门标注使用@ConfigurationProperties注解绑定属性的bean是哪些，使用步骤如下
步骤①：在配置类上开启@EnableConfigurationProperties注解，并且标注要使用@ConfigurationProperties注解绑定属性的类
@SpringBootApplication
@EnableConfigurationProperties(ServerConfig.class)
public class Springboot13ConfigurationApplication {
}步骤②：在对应的类上直接使用@ConfigurationProperties进行属性绑定
@Data
@ConfigurationProperties(prefix="servers")
publicclassServerConfig {
privateStringipAddress;
privateintport;
privatelongtimeout;
}注意：此时在该类的上方就不能使用@Componet注解定义bean，会出现bean不唯一定义异常
@EnableConfigurationProperties告诉Spring开启配置文件属性注入功能，且有哪些类要加载配置文件中的属性，而读取Spring的配置文件的前提是这个类要被Spring容器所管理，所以Spring会自动将定义在这个注解内部的类声明为一个bean
最后再说一个小技巧，使用@ConfigurationProperties注解时，会出现一个提示信息
出现这个提示后只需要添加一个坐标此提醒就消失了
org.springframework.boot
spring-boot-configuration-processor
总结
使用@ConfigurationProperties可以为使用@Bean声明的第三方bean绑定属性
当使用@EnableConfigurationProperties声明进行属性绑定的bean后，无需使用@Component注解再次进行bean声明
2.2 松散绑定
在进行属性绑定时，可能会遇到如下情况，为了进行标准命名，开发者会将属性名严格按照驼峰命名法书写，在yml配置文件中将datasource修改为dataSource，如下：
dataSource:
driverClassName: com.mysql.jdbc.Driver此时程序可以正常运行，然后又将代码中的前缀datasource修改为dataSource，如下：
@Bean
@ConfigurationProperties(prefix="dataSource")
publicDruidDataSourcedatasource(){
DruidDataSourceds=newDruidDataSource();
returnds;
}此时就发生了编译错误，而且并不是idea工具导致的，运行后依然会出现问题，配置属性名dataSource是无效的
Configurationpropertyname'dataSource'isnotvalid:
Invalidcharacters:'S'
Bean:datasource
Reason:Canonicalnamesshouldbekebab-case('-'separated),lowercasealpha-numericcharactersandmuststartwithaletter
Action:Modify'dataSource'sothatitconformstothecanonicalnamesrequirements.为什么会出现这种问题，这就要来说一说springboot进行属性绑定时的一个重要知识点了，有关属性名称的宽松绑定，也可以称为宽松绑定。
宽松绑定是springboot进行编程时人性化设计的一种体现，即配置文件中的命名格式与变量名的命名格式可以进行格式上的最大化兼容。兼容到什么程度呢？几乎主流的命名格式都支持，例如：
在ServerConfig中的属性名ipAddress
@Component
@Data
@ConfigurationProperties(prefix="servers")
publicclassServerConfig {
private String ipAddress;
}可以与下面的配置属性名规则全兼容
servers:
ipAddress: 192.168.0.2 # 驼峰模式
ip_address: 192.168.0.2 # 下划线模式
ip-address: 192.168.0.2 # 烤肉串模式
IP_ADDRESS: 192.168.0.2 # 常量模式也可以说，以上4种模式最终都可以匹配到ipAddress这个属性名。为什么这样呢？原因就是在进行匹配时，配置中的名称要去掉中划线和下划线后，忽略大小写的情况下去与java代码中的属性名进行忽略大小写的等值匹配，以上4种命名去掉下划线中划线忽略大小写后都是一个词ipaddress，java代码中的属性名忽略大小写后也是ipaddress，这样就可以进行等值匹配了，这就是为什么这4种格式都能匹配成功的原因。不过springboot官方推荐使用烤肉串模式，也就是中划线模式。
到这里我们掌握了一个知识点，就是命名的规范问题。再来看开始出现的编程错误信息
Configurationpropertyname'dataSource'isnotvalid:
Invalidcharacters:'S'
Bean:datasource
Reason:Canonicalnamesshouldbekebab-case('-'separated),lowercasealpha-numericcharactersandmuststartwithaletter
Action:Modify'dataSource'sothatitconformstothecanonicalnamesrequirements.其中Reason描述了报错的原因，规范的名称应该是烤肉串(kebab)模式(case)，即使用-分隔，使用小写字母数字作为标准字符，且必须以字母开头。然后再看我们写的名称dataSource，就不满足上述要求。闹了半天，在书写前缀时，这个词不是随意支持的，必须使用上述标准。编程写了这么久，基本上编程习惯都养成了，到这里又被springboot教育了，没辙，谁让人家东西好用呢，按照人家的要求写吧。
注意：
以上规则仅针对springboot中@ConfigurationProperties注解进行属性绑定时有效，对@Value注解进行属性映射无效。
且@ConfigurationProperties中的前缀命名仅能使用小写的数字、字母、下划线
总结
@ConfigurationProperties绑定属性时支持属性名宽松绑定，这个宽松体现在属性名的命名规则上
@Value注解不支持松散绑定规则
绑定前缀名推荐采用烤肉串命名规则，即使用中划线做分隔符，使用小写的字母、数字、下划线
2.3 常用计量单位
在前面的配置中，我们书写了如下配置值，其中第三项超时时间timeout描述了服务器操作超时时间，当前值是-1表示永不超时。
servers:
ip-address: 192.168.0.1
port: 2345
timeout: -1但是每个人都这个值的理解会产生不同，比如线上服务器完成一次主从备份，配置超时时间240，这个240如果单位是秒就是超时时间4分钟，如果单位是分钟就是超时时间4小时。面对一次线上服务器的主从备份，设置4分钟，简直是开玩笑，别说拷贝过程，备份之前的压缩过程4分钟也搞不定，这个时候问题就来了，怎么解决这个误会？
除了加强约定之外，springboot充分利用了JDK8中提供的全新的用来表示计量单位的新数据类型，从根本上解决这个问题。以下模型类中添加了两个JDK8中新增的类，分别是Duration和DataSize
@Component
@Data
@ConfigurationProperties(prefix="servers")
publicclassServerConfig {
@DurationUnit(ChronoUnit.HOURS)
private Duration serverTimeOut;
@DataSizeUnit(DataUnit.MEGABYTES)
private DataSize dataSize;
}Duration：表示时间间隔，可以通过@DurationUnit注解描述时间单位，例如上例中描述的单位为小时（ChronoUnit.HOURS）
DataSize：表示存储空间，可以通过@DataSizeUnit注解描述存储空间单位，例如上例中描述的单位为MB（DataUnit.MEGABYTES）
使用上述两个单位就可以有效避免因沟通不同步或文档不健全导致的信息不对称问题，从根本上解决了问题，避免产生误读。
2.4 bean注入数据校验
目前我们在进行属性绑定时可以通过松散绑定规则在书写时放飞自我了，但是在书写时由于无法感知模型类中的数据类型，就会出现类型不匹配的问题，比如代码中需要int类型，配置中给了非法的数值，例如写一个“a"，这种数据肯定无法有效的绑定，还会引发错误。
SpringBoot给出了强大的数据校验功能，可以有效的避免此类问题的发生。在JAVAEE的JSR303规范中给出了具体的数据校验标准，开发者可以根据自己的需要选择对应的校验框架，此处使用Hibernate提供的校验框架来作为实现进行数据校验。书写应用格式非常固定，话不多说，直接上步骤：
步骤①：导入校验框架坐标
javax.validation
validation-api
org.hibernate.validator
hibernate-validator
步骤②：在需要开启校验功能的类上使用注解@Validated开启校验功能
@Component
@Data
@ConfigurationProperties(prefix="servers")
//开启对当前bean的属性注入校验
@Validated
publicclassServerConfig {
}步骤③：对具体的字段设置校验规则
@Component
@Data
@ConfigurationProperties(prefix="servers")
//开启对当前bean的属性注入校验
@Validated
publicclassServerConfig {
//设置具体的规则
@Max(value=8888,message="最大值不能超过8888")
@Min(value=202,message="最小值不能低于202")
privateintport;
}通过设置数据格式校验，就可以有效避免非法数据加载，其实使用起来还是挺轻松的，基本上就是一个格式。
总结
开启Bean属性校验功能一共3步：
导入JSR303与Hibernate校验框架坐标、
使用@Validated注解启用校验功能、
使用具体校验规则规范数据校验格式
2.5 yaml配置进制转换
有关spring属性注入的问题到这里基本上就讲完了，但是最近一名开发者向我咨询了一个问题，我觉得需要给各位学习者分享一下。在学习阶段其实我们遇到的问题往往复杂度比较低，单一性比较强，但是到了线上开发时，都是综合性的问题，而这个开发者遇到的问题就是由于bean的属性注入引发的灾难。
先把问题描述一下，这位开发者连接数据库正常操作，但是运行程序后显示的信息是密码错误。
java.sql.SQLException:Accessdeniedforuser'root'@'localhost' (using password: YES)其实看到这个报错，几乎所有的学习者都能分辨出来，这是用户名和密码不匹配，就就是密码输入错了，但是问题就在于密码并没有输入错误，这就比较讨厌了。给的报错信息无法帮助你有效的分析问题，甚至会给你带到沟里。如果是初学者，估计这会心态就崩了，我密码没错啊，你怎么能说我有错误呢？来看看用户名密码的配置是如何写的：
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/ssm_db?serverTimezone=UTC
username: root
password: 0127 #Spring认为这是一个八进制的数，转换成10进之后注入这名开发者的生日是1月27日，所以密码就使用了0127，其实问题就出在这里了。
之前在基础篇讲属性注入时，提到过类型相关的知识，在整数相关知识中有这么一句话，支持二进制，八进制，十六进制
这个问题就处在这里了，因为0127在开发者眼中是一个字符串“0127”，但是在springboot看来，这就是一个数字，而且是一个八进制的数字。当后台使用String类型接收数据时，如果配置文件中配置了一个整数值，他是先安装整数进行处理，读取后再转换成字符串。巧了，0127撞上了八进制的格式，所以最终以十进制数字87的结果存在了。
这里提两个注意点，第一，字符串标准书写加上引号包裹，养成习惯，第二，遇到0开头的数据多注意吧。
总结
yaml文件中对于数字的定义支持进制书写格式，
如需使用字符串请使用引号明确标注
3. 测试相关
3.1 加载测试专用属性
测试过程本身并不是一个复杂的过程，但是很多情况下测试时需要模拟一些线上情况，或者模拟一些特殊情况。如果当前环境按照线上环境已经设定好了，例如是下面的配置
env:
maxMemory: 32GB
minMemory: 16GB但是你现在想测试对应的兼容性，需要测试如下配置
env:
maxMemory: 16GB
minMemory: 8GB这个时候我们能不能每次测试的时候都去修改源码application.yml中的配置进行测试呢？显然是不行的。每次测试前改过来，每次测试后改回去，这太麻烦了。于是我们就想，需要在测试环境中创建一组临时属性，去覆盖我们源码中设定的属性，这样测试用例就相当于是一个独立的环境，能够独立测试，这样就方便多了。
3.1.1临时属性
springboot已经为我们开发者早就想好了这种问题该如何解决，并且提供了对应的功能入口。在测试用例程序中，可以通过对注解@SpringBootTest添加属性来模拟临时属性。
使用注解@SpringBootTest的properties属性就可以为当前测试用例添加临时的属性，覆盖源码配置文件中对应的属性值进行测试，具体如下：
//properties属性可以为当前测试用例添加临时的属性配置
@SpringBootTest(properties= {"test.prop=testValue1"})
publicclassPropertiesAndArgsTest {
@Value("${test.prop}")
privateStringmsg;
@Test
voidtestProperties(){
System.out.println(msg);
}
}3.1.2 临时参数
除了上述这种情况，在前面讲解使用命令行启动springboot程序时讲过，通过命令行参数也可以设置属性值。而且线上启动程序时，通常都会添加一些专用的配置信息。作为运维人员他们才不懂java，更不懂这些配置的信息具体格式该怎么写，那如果我们作为开发者提供了对应的书写内容后，能否提前测试一下这些配置信息是否有效呢？
使用注解@SpringBootTest的args属性就可以为当前测试用例模拟命令行参数并进行测试。
//args属性可以为当前测试用例添加临时的命令行参数
@SpringBootTest(args={"--test.prop=testValue2"})
publicclassPropertiesAndArgsTest {
@Value("${test.prop}")
privateStringmsg;
@Test
voidtestProperties(){
System.out.println(msg);
}
}说到这里，好奇宝宝们肯定就有新问题了，如果两者共存呢？其实如果思考一下配置属性与命令行参数的加载优先级，这个结果就不言而喻了。在属性加载的优先级设定中，有明确的优先级设定顺序，还记得下面这个顺序吗？
在这个属性加载优先级的顺序中，明确规定了命令行参数的优先级排序是11，而配置属性的优先级是3，结果不言而喻了，args属性配置优先于properties属性配置加载。
总结
加载测试临时属性可以通过注解@SpringBootTest的properties和args属性进行设定，此设定应用范围仅适用于当前测试用例
思考
应用于测试环境的临时属性解决了，如果想在测试的时候临时加载一些bean能不做呢？也就是说我测试时，想搞一些独立的bean出来，专门应用于测试环境，能否实现呢？咱们下一节再讲。
3.2 加载测试专用bean
上一节提出了临时配置一些专用于测试环境的bean的需求，这一节我们就来解决这个问题。
学习过Spring的知识，我们都知道，其实一个spring环境中可以设置若干个配置文件或配置类，若干个配置信息可以同时生效。现在我们的需求就是在测试环境中再添加一个配置类，然后启动测试环境时，生效此配置就行了。其实做法和spring环境中加载多个配置信息的方式完全一样。具体操作步骤如下：
步骤①：在测试包test中创建专用的测试环境配置类
@Configuration
public class MsgConfig {
@Bean
public String msg(){
return"bean msg";
}
}上述配置仅用于演示当前实验效果，实际开发可不能这么注入String类型的数据
步骤②：在启动测试环境时，导入测试环境专用的配置类，使用@Import注解即可实现
@SpringBootTest
@Import({MsgConfig.class})
public class ConfigurationTest {
@Autowired
privateStringmsg;
@Test
void testConfiguration(){
System.out.println(msg);
}
}到这里就通过@Import属性实现了基于开发环境的配置基础上，对配置进行测试环境的追加操作，实现了1+1的配置环境效果。这样我们就可以实现每一个不同的测试用例加载不同的bean的效果，丰富测试用例的编写，同时不影响开发环境的配置。
总结
定义测试环境专用的配置类，然后通过@Import注解在具体的测试中导入临时的配置，例如测试用例，方便测试过程，且上述配置不影响其他的测试类环境
思考
当前我们已经可以实现业务层和数据层的测试，并且通过临时配置，控制每个测试用例加载不同的测试数据。但是实际企业开发不仅要保障业务层与数据层的功能安全有效，也要保障表现层的功能正常。但是我们目的对表现层的测试都是通过postman手工测试的，并没有在打包过程中体现表现层功能被测试通过。能否在测试用例中对表现层进行功能测试呢？还真可以，咱们下一节再讲。
3.3 Web环境模拟测试
在测试中对表现层功能进行测试需要一个基础和一个功能。所谓的一个基础是运行测试程序时，必须启动web环境，不然没法测试web功能。一个功能是必须在测试程序中具备发送web请求的能力，不然无法实现web功能的测试。所以在测试用例中测试表现层接口这项工作就转换成了两件事，一，如何在测试类中启动web测试，二，如何在测试类中发送web请求。下面一件事一件事进行，先说第一个
3.3.1 测试类中开启web环境
每一个springboot的测试类上方都会标准@SpringBootTest注解，而注解带有一个属性，叫做webEnvironment。通过该属性就可以设置在测试用例中启动web环境，具体如下：
@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT)
publicclassWebTest {
}测试类中启动web环境时，可以指定启动的Web环境对应的端口，springboot提供了4种设置值，分别如下：
MOCK：根据当前设置确认是否启动web环境，例如使用了Servlet的API就启动web环境，属于适配性的配置
DEFINED_PORT：使用自定义的端口作为web服务器端口
RANDOM_PORT：使用随机端口作为web服务器端口
NONE：不启动web环境
通过上述配置，现在启动测试程序时就可以正常启用web环境了，建议大家测试时使用RANDOM_PORT，避免代码中因为写死设定引发线上功能打包测试时由于端口冲突导致意外现象的出现。就是说你程序中写了用8080端口，结果线上环境8080端口被占用了，结果你代码中所有写的东西都要改，这就是写死代码的代价。现在你用随机端口就可以测试出来你有没有这种问题的隐患了。
测试环境中的web环境已经搭建好了，下面就可以来解决第二个问题了，如何在程序代码中发送web请求。
3.3.2 测试类中发送web请求
对于测试类中发送请求，其实java的API就提供对应的功能，只不过平时各位小伙伴接触的比较少，所以较为陌生。springboot为了便于开发者进行对应的功能开发，对其又进行了包装，简化了开发步骤，具体操作如下：
步骤①：在测试类中开启web虚拟调用功能，通过注解@AutoConfigureMockMvc实现此功能的开启
@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT)
//开启虚拟MVC调用
@AutoConfigureMockMvc
public class WebTest {
}步骤②：定义发起虚拟调用的对象MockMVC，通过自动装配的形式初始化对象
@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT)
//开启虚拟MVC调用
@AutoConfigureMockMvc
public class WebTest {
@Test
voidtestWeb(@Autowired MockMvc mvc) {
}
}步骤③：创建一个虚拟请求对象，封装请求的路径，并使用MockMVC对象发送对应请求
@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT)
//1、开启虚拟MVC调用开关
@AutoConfigureMockMvc
public class WebTest {
@Test
voidtestWeb(@Autowired MockMvcmvc) throwsException {
//http://localhost:8080/books
//MockMvcRequestBuilders工具类，用于创建虚拟请求
//2、创建虚拟请求，当前访问路径为/books，访问方式为get
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
//3、执行对应的请求
mvc.perform(builder);
}
}执行测试程序，现在就可以正常的发送/books对应的请求了，注意访问路径不要写http://localhost:8080/books，因为前面的服务器IP地址和端口使用的是当前虚拟的web环境，无需指定，仅指定请求的具体路径即可。
总结
在测试类中测试web层接口要保障测试类启动时启动web容器，使用@SpringBootTest注解的webEnvironment属性可以虚拟web环境用于测试
为测试方法注入MockMvc对象，通过MockMvc对象可以发送虚拟请求，模拟web请求调用过程
思考
目前已经成功的发送了请求，但是还没有起到测试的效果，测试过程必须出现预计值与真实值的比对结果才能确认测试结果是否通过，虚拟请求中能对哪些请求结果进行比对呢？咱们下一节再讲。
3.3.3 web环境请求结果比对
上一节已经在测试用例中成功的模拟出了web环境，并成功的发送了web请求，本节就来解决发送请求后如何比对发送结果的问题。其实发完请求得到的信息只有一种，就是响应对象。至于响应对象中包含什么，就可以比对什么。常见的比对内容如下：
响应状态匹配
@Test
voidtestStatus(@Autowired MockMvcmvc) throws Exception {
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
ResultActions action = mvc.perform(builder);
// 设定预期值 与真实值进行比较，成功测试通过，失败测试失败
// 1、使用提供的结果匹配器接口，设定匹配的预期值类型，此处使用状态码
StatusResultMatchers status = MockMvcResultMatchers.status();
// 2、设定具体的预期结果，此处为响应成功，状态码：200
ResultMatcher ok = status.isOk();
// 3、将预期结果添加到本次调用过程与真实结果进行匹配（内部使用了断言）
action.andExpect(ok);
}响应体匹配（非json数据格式）
@Test
voidtestBody(@Autowired MockMvcmvc) throws Exception {
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
ResultActions action = mvc.perform(builder);
//设定预期值 与真实值进行比较，成功测试通过，失败测试失败
// 1、使用提供的结果匹配器接口，设定预期值的类型，此处使用响应体
ContentResultMatchers content = MockMvcResultMatchers.content();
// 2、设定具体的预期结果，此处为响应体：springboot，把预计的内容转换成字符串进行匹配
ResultMatcher result = content.string("springboot");
// 3、为本次调用添加预期值，将预期结果添加到本次套用的真实结果进行匹配
action.andExpect(result);
}响应体匹配（json数据格式，开发中的主流使用方式）
@Test
voidtestJson(@Autowired MockMvcmvc) throws Exception {
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
ResultActions action = mvc.perform(builder);
//设定预期值 与真实值进行比较，成功测试通过，失败测试失败
//定义本次调用的预期值
ContentResultMatchers content = MockMvcResultMatchers.content();
ResultMatcher result = content.json("{\"id\":1,\"name\":\"springboot2\",\"type\":\"springboot\"}");
//添加预计值到本次调用过程中进行匹配
action.andExpect(result);
}响应头信息匹配
@Test
voidtestContentType(@Autowired MockMvcmvc) throws Exception {
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
ResultActions action = mvc.perform(builder);
//设定预期值 与真实值进行比较，成功测试通过，失败测试失败
//定义本次调用的预期值
HeaderResultMatchers header = MockMvcResultMatchers.header();
ResultMatcher contentType = header.string("Content-Type", "application/json");
//添加预计值到本次调用过程中进行匹配
action.andExpect(contentType);
}在实际开发中，一个测试用例会进行多种类型结果的校验。以下范例就是三种信息同时进行匹配校验，也是一个完整的信息匹配过程。
@Test
void testGetById(@Autowired MockMvc mvc) throws Exception {
MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
ResultActions action = mvc.perform(builder);
StatusResultMatchers status = MockMvcResultMatchers.status();
ResultMatcher ok = status.isOk();
action.andExpect(ok);
HeaderResultMatchers header = MockMvcResultMatchers.header();
ResultMatcher contentType = header.string("Content-Type", "application/json");
action.andExpect(contentType);
ContentResultMatchers content = MockMvcResultMatchers.content();
ResultMatcher result = content.json("{\"id\":1,\"name\":\"springboot\",\"type\":\"springboot\"}");
action.andExpect(result);
}总结
web虚拟调用可以对本地虚拟请求的返回响应信息进行比对，分为响应头信息比对、响应体信息比对、响应状态信息比对
3.4 测试数据回滚
当前我们的测试程序可以完美的进行表现层、业务层、数据层接口对应的功能测试了，但是测试用例开发完成后，在打包的阶段由于test生命周期属于必须被运行的生命周期，如果跳过会给系统带来极高的安全隐患，所以测试用例必须执行。
但是新的问题就呈现了，测试用例如果测试时产生了事务提交就会在测试过程中对数据库数据产生影响，进而产生垃圾数据。这个过程不是我们希望发生的，作为开发者测试用例该运行运行，但是过程中产生的数据不要在我的系统中留痕，这样该如何处理呢？
springboot早就为开发者想到了这个问题，并且针对此问题给出了最简解决方案，在原始测试用例中添加注解@Transactional即可实现当前测试用例的事务不提交。当程序运行后，只要@Transactional出现的位置存在注解@SpringBootTest，springboot就会认为这是一个测试程序，无需提交事务，所以也就可以避免事务的提交。
注：此处的@Transactional与Spirng中的事务注解@Transactional不是同一个
@SpringBootTest
@Transactional
@Rollback(true)
public class DaoTest {
@Autowired
private BookService bookService;
@Test
void testSave(){
Book book = new Book();
book.setName("springboot3");
book.setType("springboot3");
book.setDescription("springboot3");
bookService.save(book);
}
}如果开发者想提交事务，也可以，再添加一个@RollBack的注解，设置回滚状态为false即可正常提交事务，是不是很方便？springboot在辅助开发者日常工作这一块展现出了惊人的能力，实在太贴心了。
总结
在springboot的测试类中通过添加注解@Transactional来阻止测试用例提交事务
通过注解@Rollback控制springboot测试类执行结果是否提交事务，需要配合注解@Transactional使用
思考
当前测试程序已经近乎完美了，但是由于测试用例中书写的测试数据属于固定数据，往往失去了测试的意义，开发者可以针对测试用例进行针对性开发，这样就有可能出现测试用例不能完美呈现业务逻辑代码是否真实有效的达成业务目标的现象，解决方案其实很容易想，测试用例的数据只要随机产生就可以了，能实现吗？咱们下一节再讲。
3.5 随机测试用例数据
对于测试用例的数据固定书写肯定是不合理的，springboot提供了在配置中使用随机值的机制，确保每次运行程序加载的数据都是随机的。具体如下：
testcase:
book:
id: ${random.int}
id2: ${random.int(10)}
type: ${random.int!5,10!}
name: ${random.value}
uuid: ${random.uuid}
publishTime: ${random.long}当前配置就可以在每次运行程序时创建一组随机数据，避免每次运行时数据都是固定值的尴尬现象发生，有助于测试功能的进行。数据的加载按照之前加载数据的形式，使用@ConfigurationProperties注解即可
@Component
@Data
@ConfigurationProperties(prefix = "testcase.book")
public class BookCase {
private int id;
private int id2;
private int type;
private String name;
private String uuid;
private long publishTime;
}对于随机值的产生，还有一些小的限定规则，比如产生的数值性数据可以设置范围等，具体如下：
${random.int}表示随机整数
${random.int(10)}表示10以内的随机数
${random.int(10,20)}表示10到20的随机数
其中()可以是任意字符，例如[]，!!均可
总结
使用随机数据可以替换测试用例中书写的固定数据，提高测试用例中的测试数据有效性
4. 数据层实现方案
4.1 SQL
回忆一下之前做SSMP整合的时候数据层解决方案涉及到了哪些技术？MySQL数据库与MyBatisPlus框架，后面又学了Druid数据源的配置，所以现在数据层解决方案可以说是Mysql+Druid+MyBatisPlus。而三个技术分别对应了数据层操作的三个层面：
数据源技术：Druid
持久化技术：MyBatisPlus
数据库技术：MySQL
下面的研究就分为三个层面进行研究，对应上面列出的三个方面，咱们就从第一个数据源技术开始说起。
4.1.1 数据源
目前我们使用的数据源技术是Druid，运行时可以在日志中看到对应的数据源初始化信息，具体如下：
INFO28600---[ main]c.a.d.s.b.a.DruidDataSourceAutoConfigure:InitDruidDataSource
INFO28600---[ main]com.alibaba.druid.pool.DruidDataSource :{dataSource-1}inited如果不使用Druid数据源，程序运行后是什么样子呢？是独立的数据库连接对象还是有其他的连接池技术支持呢？将Druid技术对应的starter去掉再次运行程序可以在日志中找到如下初始化信息：
INFO31820---[ main]com.zaxxer.hikari.HikariDataSource :HikariPool-1-Starting...
INFO31820---[ main]com.zaxxer.hikari.HikariDataSource :HikariPool-1-Startcompleted.虽然没有DruidDataSource相关的信息了，但是我们发现日志中有HikariDataSource这个信息，就算不懂这是个什么技术，看名字也能看出来，以DataSource结尾的名称，这一定是一个数据源技术。我们又没有手工添加这个技术，这个技术哪里来的呢？这就是这一节要讲的知识，springboot内嵌数据源。
数据层技术是每一个企业级应用程序都会用到的，而其中必定会进行数据库连接的管理。springboot根据开发者的习惯出发，开发者提供了数据源技术，就用你提供的，开发者没有提供，那总不能手工管理一个一个的数据库连接对象啊，怎么办？我给你一个默认的就好了，这样省心又省事，大家都方便。
springboot提供了3款内嵌数据源技术，分别如下：
HikariCP
Tomcat提供DataSource
Commons DBCP
第一种，HikartCP，这是springboot官方推荐的数据源技术，作为默认内置数据源使用。啥意思？你不配置数据源，那就用这个。
第二种，Tomcat提供的DataSource，如果不想用HikartCP，并且使用tomcat作为web服务器进行web程序的开发，使用这个。为什么是Tomcat，不是其他web服务器呢？因为web技术导入starter后，默认使用内嵌tomcat，既然都是默认使用的技术了，那就一用到底，数据源也用它的。有人就提出怎么才能不使用HikartCP用tomcat提供的默认数据源对象呢？把HikartCP技术的坐标排除掉就OK了。
第三种，DBCP，这个使用的条件就更苛刻了，既不使用HikartCP也不使用tomcat的DataSource时，默认给你用这个。
springboot这心操的，也是稀碎啊，就怕你自己管不好连接对象，给你一顿推荐，真是开发界的最强辅助。既然都给你奶上了，那就受用吧，怎么配置使用这些东西呢？之前我们配置druid时使用druid的starter对应的配置如下：
spring:
datasource:
druid:
url: jdbc:mysql://localhost:3306/ssm_db?serverTimezone=UTC
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: root换成是默认的数据源HikariCP后，直接吧druid删掉就行了，如下：
spring:
datasource:
url: jdbc:mysql://localhost:3306/ssm_db?serverTimezone=UTC
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: root
当然，也可以写上是对hikari做的配置，但是url地址要单独配置，如下：
spring:
datasource:
url: jdbc:mysql://localhost:3306/ssm_db?serverTimezone=UTC
hikari:
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: root 这就是配置hikari数据源的方式。如果想对hikari做进一步的配置，可以继续配置其独立的属性。例如：
spring:
datasource:
url: jdbc:mysql://localhost:3306/ssm_db?serverTimezone=UTC
hikari:
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: root
maximum-pool-size: 50如果不想使用hikari数据源，使用tomcat的数据源或者DBCP配置格式也是一样的。学习到这里，以后我们做数据层时，数据源对象的选择就不再是单一的使用druid数据源技术了，可以根据需要自行选择。
总结
springboot技术提供了3种内置的数据源技术，分别是Hikari、tomcat内置数据源、DBCP
4.1.2 持久化技术(了解)
说完数据源解决方案，再来说一下持久化解决方案。springboot充分发挥其最强辅助的特征，给开发者提供了一套现成的数据层技术，叫做JdbcTemplate。其实这个技术不能说是springboot提供的，因为不使用springboot技术，一样能使用它，谁提供的呢？spring技术提供的，所以在springboot技术范畴中，这个技术也是存在的，毕竟springboot技术是加速spring程序开发而创建的。
这个技术其实就是回归到jdbc最原始的编程形式来进行数据层的开发，下面直接上操作步骤：
步骤①：导入jdbc对应的坐标，记得是starter
org.springframework.boot
spring-boot-starter-jdbc
步骤②：自动装配JdbcTemplate对象
@SpringBootTest
class Springboot15SqlApplicationTests {
@Test
void testJdbcTemplate(@Autowired JdbcTemplate jdbcTemplate){
}
}步骤③：使用JdbcTemplate实现查询操作（非实体类封装数据的查询操作）
@Test
void testJdbcTemplate(@Autowired JdbcTemplate jdbcTemplate){
String sql = "select * from tbl_book";
List> maps = jdbcTemplate.queryForList(sql);
System.out.println(maps);
} 步骤④：使用JdbcTemplate实现查询操作（实体类封装数据的查询操作）
@Test
void testJdbcTemplate(@Autowired JdbcTemplate jdbcTemplate){
String sql = "select * from tbl_book";
RowMapper rm = new RowMapper() {
@Override
public Book mapRow(ResultSet rs, int rowNum) throws SQLException {
Book temp = new Book();
temp.setId(rs.getInt("id"));
temp.setName(rs.getString("name"));
temp.setType(rs.getString("type"));
temp.setDescription(rs.getString("description"));
return temp;
}
};
List list = jdbcTemplate.query(sql, rm);
System.out.println(list);
} 步骤⑤：使用JdbcTemplate实现增删改操作
@Test
void testJdbcTemplateSave(@Autowired JdbcTemplate jdbcTemplate){
String sql = "insert into tbl_book values(3,'springboot1','springboot2','springboot3')";
jdbcTemplate.update(sql);
}如果想对JdbcTemplate对象进行相关配置，可以在yml文件中进行设定，具体如下：
spring:
jdbc:
template:
query-timeout: -1 # 查询超时时间
max-rows: 500 # 最大行数
fetch-size: -1 # 缓存行数总结
SpringBoot内置JdbcTemplate持久化解决方案
使用JdbcTemplate需要导入spring-boot-starter-jdbc的坐标
4.1.3 数据库技术
截止到目前，springboot给开发者提供了内置的数据源解决方案和持久化解决方案，在数据层解决方案三件套中还剩下一个数据库，莫非springboot也提供有内置的解决方案？还真有，还不是一个，三个，这一节就来说说内置的数据库解决方案。
springboot提供了3款内置的数据库，分别是：
H2(内存级数据库)
HSQL
Derby
以上三款数据库除了可以独立安装之外，还可以像是tomcat服务器一样，采用内嵌的形式运行在spirngboot容器中。内嵌在容器中运行，那必须是java对象啊，对，这三款数据库底层都是使用java语言开发的。
我们一直使用MySQL数据库就挺好的，为什么有需求用这个呢？原因就在于这三个数据库都可以采用内嵌容器的形式运行，在应用程序运行后，如果我们进行测试工作，此时测试的数据无需存储在磁盘上，但是又要测试使用，内嵌数据库就方便了，运行在内存中，该测试测试，该运行运行，等服务器关闭后，一切烟消云散，多好，省得你维护外部数据库了。这也是内嵌数据库的最大优点，方便进行功能测试。
下面以H2数据库为例讲解如何使用这些内嵌数据库，操作步骤也非常简单，简单才好用嘛
步骤①：导入H2数据库对应的坐标，一共2个
com.h2database
h2
org.springframework.boot
spring-boot-starter-data-jpa
步骤②：将工程设置为web工程，启动工程时启动H2数据库
org.springframework.boot
spring-boot-starter-web
步骤③：通过配置开启H2数据库控制台访问程序，也可以使用其他的数据库连接软件操作
spring:
h2:
console:
enabled: true
path: /h2web端访问路径/h2，访问密码123456，如果访问失败，先配置下列数据源，启动程序运行后再次访问/h2路径就可以正常访问了
datasource:
url: jdbc:h2:~/test
hikari:
driver-class-name: org.h2.Driver
username: sa
password: 123456步骤④：使用JdbcTemplate或MyBatisPlus技术操作数据库
（略）
其实我们只是换了一个数据库而已，其他的东西都不受影响。一个重要提醒，别忘了，上线时，把内存级数据库关闭，采用MySQL数据库作为数据持久化方案，关闭方式就是设置enabled属性为false即可。
总结
H2内嵌式数据库启动方式，添加坐标，添加配置
H2数据库线上运行时请务必关闭
到这里SQL相关的数据层解决方案就讲完了，现在的可选技术就丰富的多了。
数据源技术：Druid、Hikari、tomcat DataSource、DBCP
持久化技术：MyBatisPlus、MyBatis、JdbcTemplate
数据库技术：MySQL、H2、HSQL、Derby
现在开发程序时就可以在以上技术中任选一种组织成一套数据库解决方案了。
4.2 NoSQL
SQL数据层解决方案说完了，下面来说收NoSQL数据层解决方案。这个NoSQL是什么意思呢？从字面来看，No表示否定，NoSQL就是非关系型数据库解决方案，意思就是数据该存存该取取，只是这些数据不放在关系型数据库中了，那放在哪里？自然是一些能够存储数据的其他相关技术中了，比如Redis等。本节讲解的内容就是springboot如何整合这些技术，在springboot官方文档中提供了10种相关技术的整合方案，我们将讲解国内市场上最流行的几款NoSQL数据库整合方案，分别是Redis、MongoDB、ES。
4.2.1 整合Redis
Redis是一款采用key-value数据存储格式的内存级NoSQL数据库，重点关注数据存储格式，是key-value格式，也就是键值对的存储形式。与MySQL数据库不同，MySQL数据库有表、有字段、有记录，Redis没有这些东西，就是一个名称对应一个值，并且数据以存储在内存中使用为主。什么叫以存储在内存中为主？其实Redis有它的数据持久化方案，分别是RDB和AOF，但是Redis自身并不是为了数据持久化而生的，主要是在内存中保存数据，加速数据访问的，所以说是一款内存级数据库。
Redis支持多种数据存储格式，比如可以直接存字符串，也可以存一个map集合，list集合，后面会涉及到一些不同格式的数据操作，这个需要先学习一下才能进行整合，所以在基本操作中会介绍一些相关操作。下面就先安装，再操作，最后说整合
4.2.1.1安装
windows版安装包下载地址：https://github.com/tporadowski/redis/releases
下载的安装包有两种形式，一种是一键安装的msi文件，还有一种是解压缩就能使用的zip文件，哪种形式都行，这里就不介绍安装过程了，本课程采用的是msi一键安装的msi文件进行安装的。
什么是msi，其实就是一个文件安装包，不仅安装软件，还帮你把安装软件时需要的功能关联在一起，打包操作。比如如安装序列、创建和设置安装路径、设置系统依赖项、默认设定安装选项和控制安装过程的属性。说简单点就是一站式服务，安装过程一条龙操作一气呵成，就是为小白用户提供的软件安装程序。
安装完毕后会得到如下文件，其中有两个文件对应两个命令，是启动Redis的核心命令，需要再CMD命令行模式执行。
启动服务器
redis-server.exeredis.windows.conf初学者无需调整服务器对外服务端口，默认6379。
启动客户端
redis-cli.exe如果启动redis服务器失败，可以先启动客户端，然后执行shutdown操作后退出，此时redis服务器就可以正常执行了。
4.2.1.2 基本操作
服务器启动后，使用客户端就可以连接服务器，类似于启动完MySQL数据库，然后启动SQL命令行操作数据库。
放置一个字符串数据到redis中，先为数据定义一个名称，比如name,age等，然后使用命令set设置数据到redis服务器中即可
set name itheima
set age 12从redis中取出已经放入的数据，根据名称取，就可以得到对应数据。如果没有对应数据就会得到(nil)
get name
get age以上使用的数据存储是一个名称对应一个值，如果要维护的数据过多，可以使用别的数据存储结构。例如hash，它是一种一个名称下可以存储多个数据的存储模型，并且每个数据也可以有自己的二级存储名称。向hash结构中存储数据格式如下：
hset a a1 aa1 #对外key名称是a，在名称为a的存储模型中，a1这个key中保存了数据aa1
hset a a2 aa2获取hash结构中的数据命令如下
hget aa1 #得到aa1
hget aa2 #得到aa2有关redis的基础操作就普及到这里，需要全面掌握redis技术，请参看相关教程学习。
4.2.1.3 整合
在进行整合之前先梳理一下整合的思想，springboot整合任何技术其实就是在springboot中使用对应技术的API。如果两个技术没有交集，就不存在整合的概念了。所谓整合其实就是使用springboot技术去管理其他技术，几个问题是躲不掉的。
第一，需要先导入对应技术的坐标，而整合之后，这些坐标都有了一些变化
第二，任何技术通常都会有一些相关的设置信息，整合之后，这些信息如何写，写在哪是一个问题
第三，没有整合之前操作如果是模式A的话，整合之后如果没有给开发者带来一些便捷操作，那整合将毫无意义，所以整合后操作肯定要简化一些，那对应的操作方式自然也有所不同
按照上面的三个问题去思考springboot整合所有技术是一种通用思想，在整合的过程中会逐步摸索出整合的套路，而且适用性非常强，经过若干种技术的整合后基本上可以总结出一套固定思维。
下面就开始springboot整合redis，操作步骤如下：
步骤①：导入springboot整合redis的starter坐标
org.springframework.boot
spring-boot-starter-data-redis
上述坐标可以在创建模块的时候通过勾选的形式进行选择，归属NoSQL分类中
步骤②：进行基础配置
spring:
redis:
host: localhost
port: 6379操作redis，最基本的信息就是操作哪一台redis服务器，所以服务器地址属于基础配置信息，不可缺少。但是即便你不配置，目前也是可以用的。因为以上两组信息都有默认配置，刚好就是上述配置值。
步骤③：使用springboot整合redis的专用客户端接口操作，此处使用的是RedisTemplate
@SpringBootTest
class Springboot16RedisApplicationTests {
@Autowired
private RedisTemplate redisTemplate;
@Test
void set() {
ValueOperations ops = redisTemplate.opsForValue();
ops.set("age",41);
}
@Test
void get() {
ValueOperations ops = redisTemplate.opsForValue();
Object age = ops.get("name");
System.out.println(age);
}
@Test
void hset() {
HashOperations ops = redisTemplate.opsForHash();
ops.put("info","b","bb");
}
@Test
void hget() {
HashOperations ops = redisTemplate.opsForHash();
Object val = ops.get("info", "b");
System.out.println(val);
}
}在操作redis时，需要先确认操作何种数据，根据数据种类得到操作接口。例如使用opsForValue()获取string类型的数据操作接口，使用opsForHash()获取hash类型的数据操作接口，剩下的就是调用对应api操作了。各种类型的数据操作接口如下：
总结
springboot整合redis步骤
导入springboot整合redis的starter坐标
进行基础配置
使用springboot整合redis的专用客户端接口RedisTemplate操作
4.2.1.4 StringRedisTemplate
由于redis内部不提供java对象的存储格式，因此当操作的数据以对象的形式存在时，会进行转码，转换成字符串格式后进行操作。为了方便开发者使用基于字符串为数据的操作，springboot整合redis时提供了专用的API接口StringRedisTemplate，你可以理解为这是RedisTemplate的一种指定数据泛型的操作API。
@SpringBootTest
public class StringRedisTemplateTest {
@Autowired
private StringRedisTemplate stringRedisTemplate;
@Test
void get(){
ValueOperations ops = stringRedisTemplate.opsForValue();
String name = ops.get("name");
System.out.println(name);
}
} 4.2.1.5 redis客户端选择
springboot整合redis技术提供了多种客户端兼容模式，默认提供的是lettucs客户端技术，也可以根据需要切换成指定客户端技术，例如jedis客户端技术，切换成jedis客户端技术操作步骤如下：
步骤①：导入jedis坐标
redis.clients
jedis
jedis坐标受springboot管理，无需提供版本号
步骤②：配置客户端技术类型，设置为jedis
spring:
redis:
host: localhost
port: 6379
client-type: jedis步骤③：根据需要设置对应的配置
spring:
redis:
host: localhost
port: 6379
client-type: jedis
lettuce:
pool:
max-active: 16
jedis:
pool:
max-active: 16lettcus与jedis区别
jedis连接Redis服务器是直连模式，当多线程模式下使用jedis会存在线程安全问题，解决方案可以通过配置连接池使每个连接专用，这样整体性能就大受影响
lettcus基于Netty框架进行与Redis服务器连接，底层设计中采用StatefulRedisConnection。 StatefulRedisConnection自身是线程安全的，可以保障并发访问安全问题，所以一个连接可以被多线程复用。当然lettcus也支持多连接实例一起工作
总结
springboot整合redis提供了StringRedisTemplate对象，以字符串的数据格式操作redis
如果需要切换redis客户端实现技术，可以通过配置的形式进行
4.2.2 整合MongoDB
略
4.2.3 整合ES
NoSQL解决方案已经讲完了两种技术的整合了，Redis可以使用内存加载数据并实现数据快速访问，MongoDB可以在内存中存储类似对象的数据并实现数据的快速访问，在企业级开发中对于速度的追求是永无止境的。下面要讲的内容也是一款NoSQL解决方案，只不过他的作用不是为了直接加速数据的读写，而是加速数据的查询的，叫做ES技术。
ES（Elasticsearch）是一个分布式全文搜索引擎，重点是全文搜索。
那什么是全文搜索呢？比如用户要买一本书，以Java为关键字进行搜索，不管是书名中还是书的介绍中，甚至是书的作者名字，只要包含java就作为查询结果返回给用户查看，上述过程就使用了全文搜索技术。搜索的条件不再是仅用于对某一个字段进行比对，而是在一条数据中使用搜索条件去比对更多的字段，只要能匹配上就列入查询结果，这就是全文搜索的目的。而ES技术就是一种可以实现上述效果的技术。
要实现全文搜索的效果，不可能使用数据库中like操作去进行比对，这种效率太低了。ES设计了一种全新的思想，来实现全文搜索。具体操作过程如下：
将被查询的字段的数据全部文本信息进行查分，分成若干个词
例如“中华人民共和国”就会被拆分成三个词，分别是“中华”、“人民”、“共和国”，此过程有专业术语叫做分词。分词的策略不同，分出的效果不一样，不同的分词策略称为分词器。
将分词得到的结果存储起来，对应每条数据的id
例如id为1的数据中名称这一项的值是“中华人民共和国”，那么分词结束后，就会出现“中华”对应id为1，“人民”对应id为1，“共和国”对应id为1
例如id为2的数据中名称这一项的值是“人民代表大会“，那么分词结束后，就会出现“人民”对应id为2，“代表”对应id为2，“大会”对应id为2
此时就会出现如下对应结果，按照上述形式可以对所有文档进行分词。需要注意分词的过程不是仅对一个字段进行，而是对每一个参与查询的字段都执行，最终结果汇总到一个表格中
分词结果关键字 |
对应id |
中华 |
1 |
人民 |
1,2 |
共和国 |
1 |
代表 |
2 |
大会 |
2 |
当进行查询时，如果输入“人民”作为查询条件，可以通过上述表格数据进行比对，得到id值1,2，然后根据id值就可以得到查询的结果数据了。
上述过程中分词结果关键字内容每一个都不相同，作用有点类似于数据库中的索引，是用来加速数据查询的。但是数据库中的索引是对某一个字段进行添加索引，而这里的分词结果关键字不是一个完整的字段值，只是一个字段中的其中的一部分内容。并且索引使用时是根据索引内容查找整条数据，全文搜索中的分词结果关键字查询后得到的并不是整条的数据，而是数据的id，要想获得具体数据还要再次查询，因此这里为这种分词结果关键字起了一个全新的名称，叫做倒排索引。
通过上述内容的学习，发现使用ES其实准备工作还是挺多的，必须先建立文档的倒排索引，然后才能继续使用。快速了解一下ES的工作原理，下面直接开始我们的学习，老规矩，先安装，再操作，最后说整合。
4.2.3.1 安装
windows版安装包下载地址：https://www.elastic.co/cn/downloads/elasticsearch
下载的安装包是解压缩就能使用的zip文件，解压缩完毕后会得到如下文件
bin目录：包含所有的可执行命令
config目录：包含ES服务器使用的配置文件
jdk目录：此目录中包含了一个完整的jdk工具包，版本17，当ES升级时，使用最新版本的jdk确保不会出现版本支持性不足的问题
lib目录：包含ES运行的依赖jar文件
logs目录：包含ES运行后产生的所有日志文件
modules目录：包含ES软件中所有的功能模块，也是一个一个的jar包。和jar目录不同，jar目录是ES运行期间依赖的jar包，modules是ES软件自己的功能jar包
plugins目录：包含ES软件安装的插件，默认为空
启动服务器
双击elasticsearch.bat文件即可启动ES服务器，默认服务端口9200。通过浏览器访问http://localhost:9200看到如下信息视为ES服务器正常启动
{
"name":"CZBK-**********",
"cluster_name":"elasticsearch",
"cluster_uuid":"j137DSswTPG8U4Yb-0T1Mg",
"version":{
"number":"7.16.2",
"build_flavor":"default",
"build_type":"zip",
"build_hash":"2b937c44140b6559905130a8650c64dbd0879cfb",
"build_date":"2021-12-18T19:42:46.604893745Z",
"build_snapshot":false,
"lucene_version":"8.10.1",
"minimum_wire_compatibility_version":"6.8.0",
"minimum_index_compatibility_version":"6.0.0-beta1"
},
"tagline":"You Know, for Search"
}4.2.3.2 基本操作
ES文档概念及基本操作
ES中保存有我们要查询的数据，只不过格式和数据库存储数据格式不同而已。在ES中我们要先创建倒排索引，这个索引的功能又点类似于数据库的表，然后将数据添加到倒排索引中，添加的数据称为文档。所以要进行ES的操作要先创建索引，再添加文档，这样才能进行后续的查询操作。
要操作ES可以通过Rest风格的请求来进行，也就是说发送一个请求就可以执行一个操作。比如新建索引，删除索引这些操作都可以使用发送请求的形式来进行。
创建索引，books是索引名称，下同
PUT请求 http://localhost:9200/books发送请求后，看到如下信息即索引创建成功
{
"acknowledged": true,
"shards_acknowledged": true,
"index": "books"
}重复创建已经存在的索引会出现错误信息，reason属性中描述错误原因
{
"error": {
"root_cause": [
{
"type": "resource_already_exists_exception",
"reason": "index [books/VgC_XMVAQmedaiBNSgO2-w] already exists",
"index_uuid": "VgC_XMVAQmedaiBNSgO2-w",
"index": "books"
}
],
"type": "resource_already_exists_exception",
"reason": "index [books/VgC_XMVAQmedaiBNSgO2-w] already exists", # books索引已经存在
"index_uuid": "VgC_XMVAQmedaiBNSgO2-w",
"index": "book"
},
"status": 400
}查询索引
GET请求 http://localhost:9200/books查询索引得到索引相关信息，如下
{
"book": {
"aliases": {},
"mappings": {},
"settings": {
"index": {
"routing": {
"allocation": {
"include": {
"_tier_preference": "data_content"
}
}
},
"number_of_shards": "1",
"provided_name": "books",
"creation_date": "1645768584849",
"number_of_replicas": "1",
"uuid": "VgC_XMVAQmedaiBNSgO2-w",
"version": {
"created": "7160299"
}
}
}
}
}如果查询了不存在的索引，会返回错误信息，例如查询名称为book的索引后信息如下
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index [book]",
"resource.type": "index_or_alias",
"resource.id": "book",
"index_uuid": "_na_",
"index": "book"
}
],
"type": "index_not_found_exception",
"reason": "no such index [book]", # 没有book索引
"resource.type": "index_or_alias",
"resource.id": "book",
"index_uuid": "_na_",
"index": "book"
},
"status": 404
}删除索引
DELETE请求 http://localhost:9200/books删除所有后，给出删除结果
{
"acknowledged": true
}
如果重复删除，会给出错误信息，同样在reason属性中描述具体的错误原因
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index [books]",
"resource.type": "index_or_alias",
"resource.id": "book",
"index_uuid": "_na_",
"index": "book"
}
],
"type": "index_not_found_exception",
"reason": "no such index [books]", # 没有books索引
"resource.type": "index_or_alias",
"resource.id": "book",
"index_uuid": "_na_",
"index": "book"
},
"status": 404
}创建索引并指定分词器
前面创建的索引是未指定分词器的，可以在创建索引时添加请求参数，设置分词器。目前国内较为流行的分词器是IK分词器，使用前先在下对应的分词器，然后使用。IK分词器下载地址：https://github.com/medcl/elasticsearch-analysis-ik/releases
分词器下载后解压到ES安装目录的plugins目录中即可，安装分词器后需要重新启动ES服务器。使用IK分词器创建索引格式：
PUT请求 http://localhost:9200/books请求参数如下（注意是json格式的参数）
{
"mappings":{ #定义mappings属性，替换创建索引时对应的mappings属性
"properties":{ #定义索引中包含的属性设置
"id":{ #设置索引中包含id属性
"type":"keyword" #当前属性可以被直接搜索
},
"name":{ #设置索引中包含name属性
"type":"text", #当前属性是文本信息，参与分词
"analyzer":"ik_max_word", #使用IK分词器进行分词
"copy_to":"all" #分词结果拷贝到all属性中
},
"type":{
"type":"keyword"
},
"description":{
"type":"text",
"analyzer":"ik_max_word",
"copy_to":"all"
},
"all":{ #定义属性，用来描述多个字段的分词结果集合，当前属性可以参与查询
"type":"text",
"analyzer":"ik_max_word"
}
}
}
}创建完毕后返回结果和不使用分词器创建索引的结果是一样的，此时可以通过查看索引信息观察到添加的请求参数mappings已经进入到了索引属性中
{
"books": {
"aliases": {},
"mappings": { #mappings属性已经被替换
"properties": {
"all": {
"type": "text",
"analyzer": "ik_max_word"
},
"description": {
"type": "text",
"copy_to": [
"all"
],
"analyzer": "ik_max_word"
},
"id": {
"type": "keyword"
},
"name": {
"type": "text",
"copy_to": [
"all"
],
"analyzer": "ik_max_word"
},
"type": {
"type": "keyword"
}
}
},
"settings": {
"index": {
"routing": {
"allocation": {
"include": {
"_tier_preference": "data_content"
}
}
},
"number_of_shards": "1",
"provided_name": "books",
"creation_date": "1645769809521",
"number_of_replicas": "1",
"uuid": "DohYKvr_SZO4KRGmbZYmTQ",
"version": {
"created": "7160299"
}
}
}
}
}目前我们已经有了索引了，但是索引中还没有数据，所以要先添加数据，ES中称数据为文档，下面进行文档操作。
添加文档，有三种方式：
POST请求 http://localhost:9200/books/_doc #使用系统生成id
POST请求 http://localhost:9200/books/_create/1 #使用指定id
POST请求 http://localhost:9200/books/_doc/1 #使用指定id，不存在创建，存在更新（版本递增）文档属性内容通过请求参数传递，数据格式json：
{
"name":"springboot",
"type":"springboot",
"description":"springboot"
} 查询文档
GET请求 http://localhost:9200/books/_doc/1 #查询单个文档
GET请求 http://localhost:9200/books/_search #查询全部文档 条件查询
GET请求 http://localhost:9200/books/_search?q=name:springboot # q=查询属性名:查询属性值删除文档
DELETE请求 http://localhost:9200/books/_doc/1PUT修改文档（全覆盖更新）
操作整个文档
若被文档中存在多个属性，而修改文档时只提供其中一个属性，此时只会保留文档中提供的一个属性，其余属性会直接抹除
PUT请求 http://localhost:9200/books/_doc/1文档通过请求参数传递，数据格式json：
{
"name":"springboot" #修改过后，本文档只保留`name`一个属性
}POST修改文档（部分更新）
操作文档的属性（文档的下一级）
POST请求 http://localhost:9200/books/_update/1
#对1这个id指定的文档的指定属性进行修改文档通过请求参数传递，数据格式json：
{
"doc":{ #部分更新并不是对原始文档进行更新，而是对原始文档对象中的doc属性中的指定属性更新
"name":"springboot" #仅更新提供的属性值，未提供的属性值不参与更新操作
}
}4.2.3.3 整合ES客户端
略
5. 整合第三方技术
5.1 缓存技术
企业级应用主要作用是信息处理，当需要读取数据时，由于受限于数据库的访问效率，导致整体系统性能偏低。
应用程序直接与数据库打交道，访问效率低
为了改善上述现象，开发者通常会在应用程序与数据库之间建立一种临时的数据存储机制，该区域中的数据在内存中保存，读写速度较快，可以有效解决数据库访问效率低下的问题。这一块临时存储数据的区域就是缓存。
使用缓存后，应用程序与缓存打交道，缓存与数据库打交道，数据访问效率提高
缓存是什么？缓存是一种介于数据永久存储介质与应用程序之间的数据临时存储介质，使用缓存可以有效的减少低速数据读取过程的次数（例如磁盘IO），提高系统性能。此外缓存不仅可以用于提高永久性存储介质的数据读取效率，还可以提供临时的数据存储空间。而springboot提供了对市面上几乎所有的缓存技术进行整合的方案，下面就一起开启springboot整合缓存之旅。
5.1.1 SpringBoot内置缓存解决方案
springboot技术提供有内置的缓存解决方案，可以帮助开发者快速开启缓存技术，并使用缓存技术进行数据的快速操作，例如读取缓存数据和写入数据到缓存。
步骤①：导入springboot提供的缓存技术对应的starter
org.springframework.boot
spring-boot-starter-cache
步骤②：启用缓存，在引导类上方标注注解@EnableCaching配置springboot程序中可以使用缓存
@SpringBootApplication
//开启缓存功能
@EnableCaching
public class Springboot19CacheApplication {
public static void main(String[] args) {
SpringApplication.run(Springboot19CacheApplication.class, args);
}
}步骤③：设置操作的数据是否使用缓存
@Service
public class BookServiceImpl implements BookService {
@Autowired
private BookDao bookDao;
@Cacheable(value="cacheSpace",key="#id")
public Book getById(Integer id) {
return bookDao.selectById(id);
}
}在业务方法上面使用注解@Cacheable声明当前方法的返回值放入缓存中，其中要指定缓存的存储位置，以及缓存中保存当前方法返回值对应的名称。上例中value属性描述缓存的存储位置，可以理解为是一个存储空间名，key属性描述了缓存中保存数据的名称，使用#id读取形参中的id值作为缓存名称。
使用@Cacheable注解后，执行当前操作，如果发现对应名称在缓存中没有数据，就正常读取数据，然后将方法返回值放入缓存；如果对应名称在缓存中有数据，就终止当前业务方法执行，直接返回缓存中的数据。
5.1.2手机验证码案例
为了便于下面演示各种各样的缓存技术，我们创建一个手机验证码的案例环境，模拟使用缓存保存手机验证码的过程。
手机验证码案例需求如下：
输入手机号获取验证码，组织文档以短信形式发送给用户（页面模拟）
输入手机号和验证码验证结果
为了描述上述操作，我们制作两个表现层接口，一个用来模拟发送短信的过程，其实就是根据用户提供的手机号生成一个验证码，然后放入缓存，另一个用来模拟验证码校验的过程，其实就是使用传入的手机号和验证码进行匹配，并返回最终匹配结果。下面直接制作本案例的模拟代码，先以上例中springboot提供的内置缓存技术来完成当前案例的制作。
步骤①：导入springboot提供的缓存技术对应的starter
org.springframework.boot
spring-boot-starter-cache
步骤②：启用缓存，在引导类上方标注注解@EnableCaching配置springboot程序中可以使用缓存
@SpringBootApplication
//开启缓存功能
@EnableCaching
public class Springboot19CacheApplication {
public static void main(String[] args) {
SpringApplication.run(Springboot19CacheApplication.class, args);
}
}步骤③：定义验证码对应的实体类，封装手机号与验证码两个属性
@Data
public class SMSCode {
private String tele;
private String code;
}步骤④：定义验证码功能的业务层接口与实现类
public interface SMSCodeService {
public String sendCodeToSMS(String tele);
public boolean checkCode(SMSCode smsCode);
}
@Service
public class SMSCodeServiceImpl implements SMSCodeService {
@Autowired
private CodeUtils codeUtils;
@CachePut(value = "smsCode", key = "#tele")
public String sendCodeToSMS(String tele) {
String code = codeUtils.generator(tele);
return code;
}
public boolean checkCode(SMSCode smsCode) {
//取出内存中的验证码与传递过来的验证码比对，如果相同，返回true
String code = smsCode.getCode();
String cacheCode = codeUtils.get(smsCode.getTele());
return code.equals(cacheCode);
}
}获取验证码后，当验证码失效时必须重新获取验证码，因此在获取验证码的功能上不能使用@Cacheable注解，@Cacheable注解是缓存中没有值则放入值，缓存中有值则取值。此处的功能仅仅是生成验证码并放入缓存，并不具有从缓存中取值的功能，因此不能使用@Cacheable注解，应该使用仅具有向缓存中保存数据的功能，使用@CachePut注解即可。
对于校验验证码的功能建议放入工具类中进行。
步骤⑤：定义验证码的生成策略与根据手机号读取验证码的功能
@Component
public class CodeUtils {
private String [] patch = {"000000","00000","0000","000","00","0",""};
public String generator(String tele){
int hash = tele.hashCode();
int encryption = 20206666;
long result = hash ^ encryption;
long nowTime = System.currentTimeMillis();
result = result ^ nowTime;
long code = result % 1000000;
code = code < 0 ? -code : code;
String codeStr = code + "";
int len = codeStr.length();
return patch[len] + codeStr;
}
@Cacheable(value = "smsCode",key="#tele")
public String get(String tele){
return null;
}
}步骤⑥：定义验证码功能的web层接口，一个方法用于提供手机号获取验证码，一个方法用于提供手机号和验证码进行校验
@RestController
@RequestMapping("/sms")
public class SMSCodeController {
@Autowired
private SMSCodeService smsCodeService;
@GetMapping
public String getCode(String tele){
String code = smsCodeService.sendCodeToSMS(tele);
return code;
}
@PostMapping
public boolean checkCode(SMSCode smsCode){
return smsCodeService.checkCode(smsCode);
}
}5.1.3 SpringBoot整合Ehcache缓存
手机验证码的案例已经完成了，下面就开始springboot整合各种各样的缓存技术，第一个整合Ehcache技术。Ehcache是一种缓存技术，使用springboot整合Ehcache其实就是变更一下缓存技术的实现方式，话不多说，直接开整
步骤①：导入Ehcache的坐标
net.sf.ehcache
ehcache
此处为什么不是导入Ehcache的starter，而是导入技术坐标呢？其实springboot整合缓存技术做的是通用格式，不管你整合哪种缓存技术，只是实现变化了，操作方式一样。这也体现出springboot技术的优点，统一同类技术的整合方式。
步骤②：配置缓存技术实现使用Ehcache
spring:
cache:
type: ehcache
ehcache:
config: ehcache.xml配置缓存的类型type为ehcache，此处需要说明一下，当前springboot可以整合的缓存技术中包含有ehcach，所以可以这样书写。其实这个type不可以随便写的，不是随便写一个名称就可以整合的。
由于ehcache的配置有独立的配置文件格式，因此还需要指定ehcache的配置文件，以便于读取相应配置
这个设定需要保障ehcache中有一个缓存空间名称叫做smsCode的配置，前后要统一。在企业开发过程中，通过设置不同名称的cache来设定不同的缓存策略，应用于不同的缓存数据。
到这里springboot整合Ehcache就做完了，可以发现一点，原始代码没有任何修改，仅仅是加了一组配置就可以变更缓存供应商了，这也是springboot提供了统一的缓存操作接口的优势，变更实现并不影响原始代码的书写。
总结
springboot使用Ehcache作为缓存实现需要导入Ehcache的坐标
修改设置，配置缓存供应商为ehcache，并提供对应的缓存配置文件
5.1.4 SpringBoot整合Redis缓存
上节使用Ehcache替换了springboot内置的缓存技术，其实springboot支持的缓存技术还很多，下面使用redis技术作为缓存解决方案来实现手机验证码案例。
比对使用Ehcache的过程，加坐标，改缓存实现类型为ehcache，做Ehcache的配置。如果还成redis做缓存呢？一模一样，加坐标，改缓存实现类型为redis，做redis的配置。差别之处只有一点，redis的配置可以在yml文件中直接进行配置，无需制作独立的配置文件。
步骤①：导入redis的坐标
org.springframework.boot
spring-boot-starter-data-redis
步骤②：配置缓存技术实现使用redis
spring:
redis:
host: localhost
port: 6379
cache:
type: redis如果需要对redis作为缓存进行配置，注意不是对原始的redis进行配置，而是配置redis作为缓存使用相关的配置，隶属于spring.cache.redis节点下，注意不要写错位置了。
spring:
redis:
host: localhost
port: 6379
cache:
type: redis
redis:
use-key-prefix: false
key-prefix: sms_
cache-null-values: false
time-to-live: 10s总结
springboot使用redis作为缓存实现需要导入redis的坐标
修改设置，配置缓存供应商为redis，并提供对应的缓存配置
5.1.5 SpringBoot整合Memcached缓存
略
5.1.6 SpringBoot整合jetcache缓存
略
5.1.7 SpringBoot整合j2cache缓存
略
5.2 定时任务
springboot整合第三方技术第二部分我们来说说任务系统，其实这里说的任务系统指的是定时任务。定时任务是企业级开发中必不可少的组成部分，诸如长周期业务数据的计算，例如年度报表，诸如系统脏数据的处理，再比如系统性能监控报告，还有抢购类活动的商品上架，这些都离不开定时任务。本节将介绍两种不同的定时任务技术。
5.2.1 Quartz
Quartz技术是一个比较成熟的定时任务框架，怎么说呢？有点繁琐，用过的都知道，配置略微复杂。springboot对其进行整合后，简化了一系列的配置，将很多配置采用默认设置，这样开发阶段就简化了很多。再学习springboot整合Quartz前先普及几个Quartz的概念。
工作（Job）：用于定义具体执行的工作
工作明细（JobDetail）：用于描述定时工作相关的信息
触发器（Trigger）：描述了工作明细与调度器的对应关系
调度器（Scheduler）：用于描述触发工作的执行规则，通常使用cron表达式定义规则
简单说就是你定时干什么事情，这就是工作，工作不可能就是一个简单的方法，还要设置一些明细信息。工作啥时候执行，设置一个调度器，可以简单理解成设置一个工作执行的时间。工作和调度都是独立定义的，它们两个怎么配合到一起呢？用触发器。完了，就这么多。下面开始springboot整合Quartz。
步骤①：导入springboot整合Quartz的starter
org.springframework.boot
spring-boot-starter-quartz
步骤②：定义任务Bean，按照Quartz的开发规范制作，继承QuartzJobBean
public class MyQuartz extends QuartzJobBean {
@Override
protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
System.out.println("quartz task run...");
}
}步骤③：创建Quartz配置类，定义工作明细（JobDetail）与触发器的（Trigger）bean
@Configuration
public class QuartzConfig {
@Bean
public JobDetail printJobDetail(){
// 绑定具体的工作，为其设定信息
return JobBuilder
.newJob(MyQuartz.class) // 绑定具体的工作
.storeDurably() // 工作持久化，防止其销毁
.build();
}
@Bean
public Trigger pringJobTrigger(){
// 调度器 Cron表达式*
ScheduleBuilder schedule = CronScheduleBuilder.cronSchedule("0/5 * * * * ?");
return TriggerBuilder
.newTrigger()
.forJob(printJobDetail()) // 绑定对应的工作明细
.withSchedule(schedule) // 设定调度器，触发器执行的时间频次
.build();
}
}工作明细中要设置对应的具体工作，使用newJob()操作传入对应的工作任务类型即可。
触发器需要绑定任务，使用forJob()操作传入绑定的工作明细对象。此处可以为工作明细设置名称然后使用名称绑定，也可以直接调用对应方法绑定。触发器中最核心的规则是执行时间，此处使用调度器定义执行时间，执行时间描述方式使用的是cron表达式。有关cron表达式的规则，各位小伙伴可以去参看相关课程学习，略微复杂，而且格式不能乱设置，不是写个格式就能用的，写不好就会出现冲突问题。
总结
springboot整合Quartz就是将Quartz对应的核心对象交给spring容器管理，包含两个对象，JobDetail和Trigger对象
JobDetail对象描述的是工作的执行信息，需要绑定一个QuartzJobBean类型的对象
Trigger对象定义了一个触发器，需要为其指定绑定的JobDetail是哪个，同时要设置执行周期调度器
思考
上面的操作看上去不多，但是Quartz将其中的对象划分粒度过细，导致开发的时候有点繁琐，spring针对上述规则进行了简化，开发了自己的任务管理组件——Task，如何用呢？咱们下节再说。
5.2.2 SpringTask
spring根据定时任务的特征，将定时任务的开发简化到了极致。怎么说呢？要做定时任务总要告诉容器有这功能吧，然后定时执行什么任务直接告诉对应的bean什么时间执行就行了，就这么简单，一起来看怎么做
步骤①：开启定时任务功能，在引导类上开启定时任务功能的开关，使用注解@EnableScheduling
@SpringBootApplication
//开启定时任务功能
@EnableScheduling
public class Springboot22TaskApplication {
public static void main(String[] args) {
SpringApplication.run(Springboot22TaskApplication.class, args);
}
}步骤②：定义Bean，在对应要定时执行的操作上方，使用注解@Scheduled定义执行的时间，执行时间的描述方式还是cron表达式
@Component
public class MyBean {
@Scheduled(cron = "0/1 * * * * ?")
public void print(){
System.out.println(Thread.currentThread().getName()+" :spring task run...");
}
}这这就完成了定时任务的配置。总体感觉其实什么东西都没少，只不过没有将所有的信息都抽取成bean，而是直接使用注解绑定定时执行任务的事情而已。
如何想对定时任务进行相关配置，可以通过配置文件进行
spring:
task:
scheduling:
pool:
size: 1 # 任务调度线程池大小 默认 1
thread-name-prefix: ssm_ # 调度线程名称前缀 默认 scheduling-
shutdown:
await-termination: false # 线程池关闭时等待所有任务完成
await-termination-period: 10s # 调度线程关闭前最大等待时间，确保最后一定关闭总结
spring task需要使用注解@EnableScheduling开启定时任务功能
为定时执行的的任务设置执行周期@Scheduled，描述方式cron表达式
5.3 发送邮件
springboot整合第三方技术第三部分我们来说说邮件系统，发邮件是java程序的基本操作，springboot整合javamail其实就是简化开发。不熟悉邮件的小伙伴可以先学习完javamail的基础操作，再来看这一部分内容才能感触到springboot整合javamail究竟简化了哪些操作。简化的多码？其实不多，差别不大，只是还个格式而已。
学习邮件发送之前先了解3个概念，这些概念规范了邮件操作过程中的标准。
SMTP（Simple Mail Transfer Protocol）：简单邮件传输协议，用于发送电子邮件的传输协议
POP3（Post Office Protocol - Version 3）：用于接收电子邮件的标准协议
IMAP（Internet Mail Access Protocol）：互联网消息协议，是POP3的替代协议
简单说就是SMPT是发邮件的标准，POP3是收邮件的标准，IMAP是对POP3的升级。我们制作程序中操作邮件，通常是发邮件，所以SMTP是使用的重点，收邮件大部分都是通过邮件客户端完成，所以开发收邮件的代码极少。除非你要读取邮件内容，然后解析，做邮件功能的统一处理。例如HR的邮箱收到求职者的简历，可以读取后统一处理。但是为什么不制作独立的投递简历的系统呢？所以说，好奇怪的需求，因为要想收邮件就要规范发邮件的人的书写格式，这个未免有点强人所难，并且极易收到外部攻击，你不可能使用白名单来收邮件。如果能使用白名单来收邮件然后解析邮件，还不如开发个系统给白名单中的人专用呢，更安全，总之就是鸡肋了。下面就开始学习springboot如何整合javamail发送邮件。
5.3.1 发送简单邮件
步骤①：导入springboot整合javamail的starter
org.springframework.boot
spring-boot-starter-mail
步骤②：配置邮箱的登录信息
spring:
mail:
host: smtp.126.com
username: [email protected]
password: testjava程序仅用于发送邮件，邮件的功能还是邮件供应商提供的，所以这里是用别人的邮件服务，要配置对应信息。
host配置的是提供邮件服务的主机协议，当前程序仅用于发送邮件，因此配置的是smtp的协议。
password并不是邮箱账号的登录密码，是邮件供应商提供的一个加密后的密码，也是为了保障系统安全性。不然外部人员通过地址访问下载了配置文件，直接获取到了邮件密码就会有极大的安全隐患。有关该密码的获取每个邮件供应商提供的方式都不一样，此处略过。可以到邮件供应商的设置页面找POP3或IMAP这些关键词找到对应的获取位置。下例仅供参考：
步骤③：使用JavaMailSender接口发送邮件
@Service
public class SendMailServiceImpl implements SendMailService {
@Autowired
private JavaMailSender javaMailSender;
//发送人
private String from = "[email protected]";
//接收人
private String to = "[email protected]";
//标题
private String subject = "测试邮件";
//正文
private String context = "测试邮件正文内容";
@Override
public void sendMail() {
SimpleMailMessage message = new SimpleMailMessage();
message.setFrom(from+"(小甜甜)");
message.setTo(to);
message.setSubject(subject);
message.setText(context);
javaMailSender.send(message);
}
}将发送邮件的必要信息（发件人、收件人、标题、正文）封装到SimpleMailMessage对象中，可以根据规则设置发送人昵称等。
5.3.2 发送带组件邮件
发送简单邮件仅需要提供对应的4个基本信息就可以了，如果想发送复杂的邮件，需要更换邮件对象。使用MimeMessage可以发送特殊的邮件。
setText()加入参数true开启对html内容的解析支持
在获取MimeMessageHelper加入参数true开启对带组件邮件的支持
@Service
public class SendMailServiecImpl2 implements SendMailServiec {
@Autowired
private JavaMailSender javaMailSender;
@Value("[email protected]")
private String from;
@Value("[email protected]")
private String to;
@Value("测试邮件")
private String subject;
@Value("
别点我")
private String text;
@Override
public void send() {
try {
MimeMessage message = javaMailSender.createMimeMessage();
//开启带组件的邮件发送支持
MimeMessageHelper helper = new MimeMessageHelper(message,true);
// 发送的附件
File f1 = new File("E:\\developer_tools\\JetBrains\\IdeaProjects\\SpringBoot\\springboot_23_mail\\target\\springboot_23_mail-0.0.1-SNAPSHOT.jar");
helper.setFrom(from);
helper.setTo(to);
helper.setSubject(subject);
// 此处设置正文支持html解析
helper.setText(text,true);
// 添加组件
helper.addAttachment(f1.getName(),f1);
javaMailSender.send(message);
} catch (MessagingException e) {
e.printStackTrace();
}
}
}总结
springboot整合javamail其实就是简化了发送邮件的客户端对象JavaMailSender的初始化过程，通过配置的形式加载信息简化开发过程
5.4 消息处理
5.4.1 消息的概念
从广义角度来说，消息其实就是信息，但是和信息又有所不同。信息通常被定义为一组数据，而消息除了具有数据的特征之外，还有消息的来源与接收的概念。通常发送消息的一方称为消息的生产者，接收消息的一方称为消息的消费者。这样比较后，发现其实消息和信息差别还是很大的。
为什么要设置生产者和消费者呢？这就是要说到消息的意义了。信息通常就是一组数据，但是消息由于有了生产者和消费者，就出现了消息中所包含的信息可以被二次解读，生产者发送消息，可以理解为生产者发送了一个信息，也可以理解为生产者发送了一个命令；消费者接收消息，可以理解为消费者得到了一个信息，也可以理解为消费者得到了一个命令。对比一下我们会发现信息是一个基本数据，而命令则可以关联下一个行为动作，这样就可以理解为基于接收的消息相当于得到了一个行为动作，使用这些行为动作就可以组织成一个业务逻辑，进行进一步的操作。总的来说，消息其实也是一组信息，只是为其赋予了全新的含义，因为有了消息的流动，并且是有方向性的流动，带来了基于流动的行为产生的全新解读。开发者就可以基于消息的这种特殊解，将其换成代码中的指令。
对于消息的理解，初学者总认为消息内部的数据非常复杂，这是一个误区。比如我发送了一个消息，要求接受者翻译发送过去的内容。初学者会认为消息中会包含被翻译的文字，已经本次操作要执行翻译操作而不是打印操作。其实这种现象有点过度解读了，发送的消息中仅仅包含被翻译的文字，但是可以通过控制不同的人接收此消息来确认要做的事情。例如发送被翻译的文字仅到A程序，而A程序只能进行翻译操作，这样就可以发送简单的信息完成复杂的业务了，是通过接收消息的主体不同，进而执行不同的操作，而不会在消息内部定义数据的操作行为，当然如果开发者希望消息中包含操作种类信息也是可以的，只是提出消息的内容可以更简单，更单一。
对于消息的生产者与消费者的工作模式，还可以将消息划分成两种模式，同步消息与异步消息。
所谓同步消息就是生产者发送完消息，等待消费者处理，消费者处理完将结果告知生产者，然后生产者继续向下执行业务。这种模式过于卡生产者的业务执行连续性，在现在的企业级开发中，上述这种业务场景通常不会采用消息的形式进行处理。
所谓异步消息就是生产者发送完消息，无需等待消费者处理完毕，生产者继续向下执行其他动作。比如生产者发送了一个日志信息给日志系统，发送过去以后生产者就向下做其他事情了，无需关注日志系统的执行结果。日志系统根据接收到的日志信息继续进行业务执行，是单纯的记录日志，还是记录日志并报警，这些和生产者无关，这样生产者的业务执行效率就会大幅度提升。并且可以通过添加多个消费者来处理同一个生产者发送的消息来提高系统的高并发性，改善系统工作效率，提高用户体验。一旦某一个消费者由于各种问题宕机了，也不会对业务产生影响，提高了系统的高可用性。
5.4.2 Java处理消息的标准规范
目前企业级开发中广泛使用的消息处理技术共三大类，具体如下：
JMS
AMQP
MQTT
为什么是三大类，而不是三个技术呢？因为这些都是规范，就想JDBC技术，是个规范，开发针对规范开发，运行还要靠实现类，例如MySQL提供了JDBC的实现，最终运行靠的还是实现。并且这三类规范都是针对异步消息进行处理的，也符合消息的设计本质，处理异步的业务。对以上三种消息规范做一下普及
JMS
JMS（Java Message Service）,这是一个规范，作用等同于JDBC规范，提供了与消息服务相关的API接口。
JMS消息模型
JMS规范中规范了消息有两种模型。分别是点对点模型和发布订阅模型。
点对点模型：peer-2-peer，生产者会将消息发送到一个保存消息的容器中，通常使用队列模型，使用队列保存消息。一个队列的消息只能被一个消费者消费，或未被及时消费导致超时。这种模型下，生产者和消费者是一对一绑定的。
发布订阅模型：publish-subscribe，生产者将消息发送到一个保存消息的容器中，也是使用队列模型来保存。但是消息可以被多个消费者消费，生产者和消费者完全独立，相互不需要感知对方的存在。
以上这种分类是从消息的生产和消费过程来进行区分，针对消息所包含的信息不同，还可以进行不同类别的划分。
JMS消息种类
根据消息中包含的数据种类划分，可以将消息划分成6种消息。
TextMessage
MapMessage
BytesMessage
StreamMessage
ObjectMessage
Message （只有消息头和属性）
JMS主张不同种类的消息，消费方式不同，可以根据使用需要选择不同种类的消息。但是这一点也成为其诟病之处，后面再说。整体上来说，JMS就是典型的保守派，什么都按照J2EE的规范来，做一套规范，定义若干个标准，每个标准下又提供一大批API。目前对JMS规范实现的消息中间件技术还是挺多的，毕竟是皇家御用，肯定有人舔，例如ActiveMQ、Redis、HornetMQ。但是也有一些不太规范的实现，参考JMS的标准设计，但是又不完全满足其规范，例如：RabbitMQ、RocketMQ。
AMQP
JMS的问世为消息中间件提供了很强大的规范性支撑，但是使用的过程中就开始被人诟病，比如JMS设置的极其复杂的多种类消息处理机制。本来分门别类处理挺好的，为什么会被诟病呢？原因就在于JMS的设计是J2EE规范，站在Java开发的角度思考问题。但是现实往往是复杂度很高的。比如我有一个.NET开发的系统A，有一个Java开发的系统B，现在要从A系统给B系统发业务消息，结果两边数据格式不统一，没法操作。JMS不是可以统一数据格式吗？提供了6种数据种类，总有一款适合你啊。NO，一个都不能用。因为A系统的底层语言不是Java语言开发的，根本不支持那些对象。这就意味着如果想使用现有的业务系统A继续开发已经不可能了，必须推翻重新做使用Java语言开发的A系统。
这时候有人就提出说，你搞那么复杂，整那么多种类干什么？找一种大家都支持的消息数据类型不就解决这个跨平台的问题了吗？大家一想，对啊，于是AMQP孕育而生。
单从上面的说明中其实可以明确感知到，AMQP的出现解决的是消息传递时使用的消息种类的问题，化繁为简，但是其并没有完全推翻JMS的操作API，所以说AMQP仅仅是一种协议，规范了数据传输的格式而已。
AMQP（advanced message queuing protocol）：一种协议（高级消息队列协议，也是消息代理规范），规范了网络交换的数据格式，兼容JMS操作。优点
具有跨平台性，服务器供应商，生产者，消费者可以使用不同的语言来实现
JMS消息种类
AMQP消息种类：byte[]
AMQP在JMS的消息模型基础上又进行了进一步的扩展，除了点对点和发布订阅的模型，开发了几种全新的消息模型，适应各种各样的消息发送。
AMQP消息模型
direct exchange
fanout exchange
topic exchange
headers exchange
system exchange
目前实现了AMQP协议的消息中间件技术也很多，而且都是较为流行的技术，例如：RabbitMQ、StormMQ、RocketMQ
MQTT
MQTT（Message Queueing Telemetry Transport）消息队列遥测传输，专为小设备设计，是物联网（IOT）生态系统中主要成分之一。由于与JavaEE企业级开发没有交集，此处不作过多的说明。
除了上述3种J2EE企业级应用中广泛使用的三种异步消息传递技术，还有一种技术也不能忽略，Kafka。
KafKa
Kafka，一种高吞吐量的分布式发布订阅消息系统，提供实时消息功能。Kafka技术并不是作为消息中间件为主要功能的产品，但是其拥有发布订阅的工作模式，也可以充当消息中间件来使用，而且目前企业级开发中其身影也不少见。
5.4.3 购物订单发送手机短信案例
为了便于下面演示各种各样的消息中间件技术，我们创建一个购物过程生成订单时为用户发送短信的案例环境，模拟使用消息中间件实现发送手机短信的过程。
手机验证码案例需求如下：
执行下单业务时（模拟此过程），调用消息服务，将要发送短信的订单id传递给消息中间件
消息处理服务接收到要发送的订单id后输出订单id（模拟发短信）
由于不涉及数据读写，仅开发业务层与表现层，其中短信处理的业务代码独立开发，代码如下：
订单业务
业务层接口
public interface OrderService {
void order(String id);
}模拟传入订单id，执行下订单业务，参数为虚拟设定，实际应为订单对应的实体类
业务层实现
@Service
public class OrderServiceImpl implements OrderService {
@Autowired
private MessageService messageService;
@Override
public void order(String id) {
//一系列操作，包含各种服务调用，处理各种业务
System.out.println("订单处理开始");
//短信消息处理
messageService.sendMessage(id);
System.out.println("订单处理结束");
System.out.println();
}
}业务层转调短信处理的服务MessageService
表现层服务
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping("{id}")
public void order(@PathVariable String id){
orderService.order(id);
}
}表现层对外开发接口，传入订单id即可（模拟）
短信处理业务
业务层接口
public interface MessageService {
void sendMessage(String id);
String doMessage();
}短信处理业务层接口提供两个操作，发送要处理的订单id到消息中间件，另一个操作目前暂且设计成处理消息，实际消息的处理过程不应该是手动执行，应该是自动执行，到具体实现时再进行设计
业务层实现
@Service
public class MessageServiceImpl implements MessageService {
private ArrayList msgList = new ArrayList();
@Override
public void sendMessage(String id) {
System.out.println("待发送短信的订单已纳入处理队列，id："+id);
msgList.add(id);
}
@Override
public String doMessage() {
String id = msgList.remove(0);
System.out.println("已完成短信发送业务，id："+id);
return id;
}
} 短信处理业务层实现中使用集合先模拟消息队列，观察效果
表现层服务
@RestController
@RequestMapping("/msgs")
public class MessageController {
@Autowired
private MessageService messageService;
@GetMapping
public String doMessage(){
String id = messageService.doMessage();
return id;
}
}短信处理表现层接口暂且开发出一个处理消息的入口，但是此业务是对应业务层中设计的模拟接口，实际业务不需要设计此接口。
下面开启springboot整合各种各样的消息中间件，从严格满足JMS规范的ActiveMQ开始
5.4.4 整合ActiveMQ
ActiveMQ是MQ产品中的元老级产品，早期标准MQ产品之一，在AMQP协议没有出现之前，占据了消息中间件市场的绝大部分份额，后期因为AMQP系列产品的出现，迅速走弱，目前仅在一些线上运行的产品中出现，新产品开发较少采用。
安装
windows版安装包下载地址：https://activemq.apache.org/components/classic/download/
下载的安装包是解压缩就能使用的zip文件，解压缩完毕后会得到如下文件
启动服务器
运行bin目录下的win32或win64目录下的activemq.bat命令即可，根据自己的操作系统选择即可，默认对外服务端口61616。
访问web管理服务
ActiveMQ启动后会启动一个Web控制台服务，可以通过该服务管理ActiveMQ。
http://127.0.0.1:8161/
web管理服务默认端口8161，访问后可以打开ActiveMQ的管理界面，如下：
首先输入访问用户名和密码，初始化用户名和密码相同，均为：admin，成功登录后进入管理后台界面，如下：
整合
步骤①：导入springboot整合ActiveMQ的starter
org.springframework.boot
spring-boot-starter-activemq
步骤②：配置ActiveMQ的服务器地址
spring:
activemq:
broker-url: tcp://localhost:61616步骤③：使用JmsMessagingTemplate操作ActiveMQ
@Service
public class MessageServiceActivemqImpl implements MessageService {
@Autowired
private JmsMessagingTemplate messagingTemplate;
@Override
public void sendMessage(String id) {
System.out.println("待发送短信的订单已纳入处理队列，id："+id);
messagingTemplate.convertAndSend("order.queue.id",id);
}
@Override
public String doMessage() {
String id = messagingTemplate.receiveAndConvert("order.queue.id",String.class);
System.out.println("已完成短信发送业务，id："+id);
return id;
}
}发送消息需要先将消息的类型转换成字符串，然后再发送，所以是convertAndSend，定义消息发送的位置，和具体的消息内容，此处使用id作为消息内容。
接收消息需要先将消息接收到，然后再转换成指定的数据类型，所以是receiveAndConvert，接收消息除了提供读取的位置，还要给出转换后的数据的具体类型。
步骤④：使用消息监听器在服务器启动后，监听指定位置，当消息出现后，立即消费消息
@Component
public class MessageListener {
@JmsListener(destination = "order.queue.id")
@SendTo("order.other.queue.id")
public String receive(String id){
System.out.println("已完成短信发送业务，id："+id);
return "new:"+id;
}
}使用注解@JmsListener定义当前方法监听ActiveMQ中指定名称的消息队列。
如果当前消息队列处理完还需要继续向下传递当前消息到另一个队列中使用注解@SendTo即可，这样即可构造连续执行的顺序消息队列。
步骤⑤：切换消息模型由点对点模型到发布订阅模型，修改jms配置即可
spring:
activemq:
broker-url: tcp://localhost:61616
jms:
pub-sub-domain: true
pub-sub-domain默认值为false，即点对点模型，修改为true后就是发布订阅模型。总结
springboot整合ActiveMQ提供了JmsMessagingTemplate对象作为客户端操作消息队列
操作ActiveMQ需要配置ActiveMQ服务器地址，默认端口61616
企业开发时通常使用监听器来处理消息队列中的消息，设置监听器使用注解@JmsListener
配置jms的pub-sub-domain属性可以在点对点模型和发布订阅模型间切换消息模型
5.4.5 整合RabbitMQ
安装
步骤①：安装Erlang
下载地址：https://www.erlang.org/downloads
配置环境变量ERLANG_HOME、PATH
步骤②：安装RabbitMQ
下载地址：https://rabbitmq.com/install-windows.html
步骤③：启动服务器：
rabbitmq-service.bat start # 启动服务
rabbitmq-service.bat stop # 停止服务
rabbitmqctl status # 查看服务状态步骤④：访问web管理服务
RabbitMQ也提供有web控制台服务，但是此功能是一个插件，需要先启用才可以使用。
rabbitmq-plugins.batlist # 查看当前所有插件的运行状态
rabbitmq-plugins.batenablerabbitmq_management # 启动rabbitmq_management插件启动插件后可以在插件运行状态中查看是否运行，运行后通过浏览器即可打开服务后台管理界面
首先输入访问用户名和密码，初始化用户名和密码相同，均为：guest，成功登录后进入管理后台界面，如下：
整合(direct模型)
RabbitMQ满足AMQP协议，因此不同的消息模型对应的制作不同，先使用最简单的direct模型开发。
步骤①：导入springboot整合amqp的starter，amqp协议默认实现为rabbitmq方案
org.springframework.boot
spring-boot-starter-amqp
步骤②：配置RabbitMQ的服务器地址
spring:
rabbitmq:
host: localhost
port: 5672步骤③：初始化直连模式系统设置
由于RabbitMQ不同模型要使用不同的交换机，因此需要先初始化RabbitMQ相关的对象，例如队列，交换机等
@Configuration
public class RabbitConfigDirect {
@Bean
public Queue directQueue(){
return new Queue("direct_queue");
}
@Bean
public Queue directQueue2(){
return new Queue("direct_queue2");
}
@Bean
public DirectExchange directExchange(){
return new DirectExchange("directExchange");
}
@Bean
public Binding bindingDirect(){
return BindingBuilder.bind(directQueue()).to(directExchange()).with("direct");
}
@Bean
public Binding bindingDirect2(){
return BindingBuilder.bind(directQueue2()).to(directExchange()).with("direct2");
}
}队列Queue与直连交换机DirectExchange创建后，还需要绑定他们之间的关系Binding，这样就可以通过交换机操作对应队列。
步骤④：使用AmqpTemplate操作RabbitMQ
@Service
public class MessageServiceRabbitmqDirectImpl implements MessageService {
@Autowired
private AmqpTemplate amqpTemplate;
@Override
public void sendMessage(String id) {
System.out.println("待发送短信的订单已纳入处理队列（rabbitmq direct），id："+id);
amqpTemplate.convertAndSend("directExchange","direct",id);
}
}amqp协议中的操作API接口名称看上去和jms规范的操作API接口很相似，但是传递参数差异很大。
步骤⑤：使用消息监听器在服务器启动后，监听指定位置，当消息出现后，立即消费消息
@Component
public class MessageListener {
@RabbitListener(queues = "direct_queue")
public void receive(String id){
System.out.println("已完成短信发送业务(rabbitmq direct)，id："+id);
}
} 使用注解@RabbitListener定义当前方法监听RabbitMQ中指定名称的消息队列。
整合(topic模型)
步骤①：同上
步骤②：同上
步骤③：初始化主题模式系统设置
@Configuration
public class RabbitConfigTopic {
@Bean
public Queue topicQueue(){
return new Queue("topic_queue");
}
@Bean
public Queue topicQueue2(){
return new Queue("topic_queue2");
}
@Bean
public TopicExchange topicExchange(){
return new TopicExchange("topicExchange");
}
@Bean
public Binding bindingTopic(){
return BindingBuilder.bind(topicQueue()).to(topicExchange()).with("topic.*.id");
}
@Bean
public Binding bindingTopic2(){
return BindingBuilder.bind(topicQueue2()).to(topicExchange()).with("topic.orders.*");
}
}主题模式支持routingKey匹配模式，*表示匹配一个单词，#表示匹配任意内容，这样就可以通过主题
交换机将消息分发到不同的队列中，详细内容请参看RabbitMQ系列课程。
匹配键 |
topic.*.* |
topic.# |
topic.order.id |
true |
true |
order.topic.id |
false |
false |
topic.sm.order.id |
false |
true |
topic.sm.id |
false |
true |
topic.id.order |
true |
true |
topic.id |
false |
true |
topic.order |
false |
true |
步骤④：使用AmqpTemplate操作RabbitMQ
@Service
public class MessageServiceRabbitmqTopicImpl implements MessageService {
@Autowired
private AmqpTemplate amqpTemplate;
@Override
public void sendMessage(String id) {
System.out.println("待发送短信的订单已纳入处理队列（rabbitmq topic），id："+id);
amqpTemplate.convertAndSend("topicExchange","topic.orders.id",id);
}
}发送消息后，根据当前提供的routingKey与绑定交换机时设定的routingKey进行匹配，规则匹配成功消息才会进入到对应的队列中。
步骤⑤：使用消息监听器在服务器启动后，监听指定队列
@Component
public class MessageListener {
@RabbitListener(queues = "topic_queue")
public void receive(String id){
System.out.println("已完成短信发送业务(rabbitmq topic 1)，id："+id);
}
@RabbitListener(queues = "topic_queue2")
public void receive2(String id){
System.out.println("已完成短信发送业务(rabbitmq topic 22222222)，id："+id);
}
}使用注解@RabbitListener定义当前方法监听RabbitMQ中指定名称的消息队列。
总结
springboot整合RabbitMQ提供了AmqpTemplate对象作为客户端操作消息队列
操作ActiveMQ需要配置ActiveMQ服务器地址，默认端口5672
企业开发时通常使用监听器来处理消息队列中的消息，设置监听器使用注解@RabbitListener
RabbitMQ有5种消息模型，使用的队列相同，但是交换机不同。交换机不同，对应的消息进入的策略也不同
5.4.6 整合RocketMQ
RocketMQ由阿里研发，后捐赠给apache基金会，目前是apache基金会顶级项目之一，也是目前市面上的MQ产品中较为流行的产品之一，它遵从AMQP协议。
安装
windows版安装包下载地址：https://rocketmq.apache.org/
RocketMQ安装后需要配置环境变量，具体如下：
ROCKETMQ_HOME
PATH
NAMESRV_ADDR （建议）： 127.0.0.1:9876
关于NAMESRV_ADDR对于初学者来说建议配置此项，也可以通过命令设置对应值，操作略显繁琐，建议配置。系统学习RocketMQ知识后即可灵活控制该项。
RocketMQ工作模式
在RocketMQ中，处理业务的服务器称为broker，生产者与消费者不是直接与broker联系的，而是通过命名服务器进行通信。broker启动后会通知命名服务器自己已经上线，这样命名服务器中就保存有所有的broker信息。当生产者与消费者需要连接broker时，通过命名服务器找到对应的处理业务的broker，因此命名服务器在整套结构中起到一个信息中心的作用。并且broker启动前必须保障命名服务器先启动。
启动服务器
mqnamesrv # 启动命名服务器
mqbroker # 启动broker运行bin目录下的mqnamesrv命令即可启动命名服务器，默认对外服务端口9876。
运行bin目录下的mqbroker命令即可启动broker服务器，如果环境变量中没有设置NAMESRV_ADDR则需要在运行mqbroker指令前通过set指令设置NAMESRV_ADDR的值，并且每次开启均需要设置此项。
测试服务器启动状态
RocketMQ提供有一套测试服务器功能的测试程序，运行bin目录下的tools命令即可使用。
toolsorg.apache.rocketmq.example.quickstart.Producer # 生产消息
toolsorg.apache.rocketmq.example.quickstart.Consumer # 消费消息整合（异步消息）
步骤①：导入springboot整合RocketMQ的starter，此坐标不由springboot维护版本
org.apache.rocketmq
rocketmq-spring-boot-starter
2.2.1
步骤②：配置RocketMQ的服务器地址
rocketmq:
name-server: localhost:9876
producer:
group: group_rocketmq
设置默认的生产者消费者所属组group。步骤③：使用RocketMQTemplate操作RocketMQ
@Service
public class MessageServiceRocketmqImpl implements MessageService {
@Autowired
private RocketMQTemplate rocketMQTemplate;
@Override
public void sendMessage(String id) {
System.out.println("待发送短信的订单已进入消息队列（rocketmq），id" + id);
// 发送同步消息，参数1：消息位置，参数2：发送的消息内容
// rocketMQTemplate.convertAndSend("order_id",id);
// 生产异步消息后的回调函数
SendCallback sendCallback = new SendCallback() {
@Override
// 发送成功执行
public void onSuccess(SendResult sendResult) {
System.out.println("发送成功");
}
@Override
// 发送失败执行
public void onException(Throwable throwable) {
System.out.println("发送失败");
}
};
// 发送异步消息（常用）
rocketMQTemplate.asyncSend("order_id",id,sendCallback);
}
}使用asyncSend方法发送异步消息。
步骤④：使用消息监听器在服务器启动后，监听指定位置，当消息出现后，立即消费消息
/**
* Rocket监听器
*/
@Component
// topic：主题名称，对应发送消息处的消息位置
// consumerGroup：绑定消费者组，对应生产者的默认组名
@RocketMQMessageListener(topic = "order_id",consumerGroup = "group_rocketmq")
public class MessageListener implements RocketMQListener {
@Override
public void onMessage(String id) {
System.out.println("已完成短信发送业务(rocketmq)，id：" + id);
}
} RocketMQ的监听器必须按照标准格式开发，实现RocketMQListener接口，泛型为消息类型。
使用注解@RocketMQMessageListener定义当前类监听RabbitMQ中指定组、指定名称的消息队列。
总结
springboot整合RocketMQ使用RocketMQTemplate对象作为客户端操作消息队列
操作RocketMQ需要配置RocketMQ服务器地址，默认端口9876
企业开发时通常使用监听器来处理消息队列中的消息，设置监听器使用注解@RocketMQMessageListener
6. 监控
监控就是通过软件的方式展示另一个软件的运行情况，运行的情况则通过各种各样的指标数据反馈给监控人员。例如网络是否顺畅、服务器是否在运行、程序的功能是否能够整百分百运行成功，内存是否够用等等。
6.1 监控的意义
对于现代的互联网程序来说，规模越来越大，功能越来越复杂，还要追求更好的客户体验，因此要监控的信息量也就比较大了。由于现在的互联网程序大部分都是基于微服务的程序，一个程序的运行需要若干个服务来保障，因此第一个要监控的指标就是服务是否正常运行，也就是监控服务状态是否处理宕机状态。
一旦发现某个服务宕机了，必须马上给出对应的解决方案，避免整体应用功能受影响。其次，由于互联网程序服务的客户量是巨大的，当客户的请求在短时间内集中达到服务器后，就会出现各种程序运行指标的波动。比如内存占用严重，请求无法及时响应处理等，这就是第二个要监控的重要指标，监控服务运行指标。
虽然软件是对外提供用户的访问需求，完成对应功能的，但是后台的运行是否平稳，是否出现了不影响客户使用的功能隐患，这些也是要密切监控的，此时就需要在不停机的情况下，监控系统运行情况，日志是一个不错的手段。如果在众多日志中找到开发者或运维人员所关注的日志信息，简单快速有效的过滤出要看的日志也是监控系统需要考虑的问题，这就是第三个要监控的指标，监控程序运行日志。
虽然我们期望程序一直平稳运行，但是由于突发情况的出现，例如服务器被攻击、服务器内存溢出等情况造成了服务器宕机，此时当前服务不能满足使用需要，就要将其重启甚至关闭，如果快速控制服务器的启停也是程序运行过程中不可回避的问题，这就是第四个监控项，管理服务状态。
以上这些仅仅是从大的方面来思考监控这个问题，还有很多的细节点，例如上线了一个新功能，定时提醒用户续费，这种功能不是上线后马上就运行的，但是当前功能是否真的启动，如果快速的查询到这个功能已经开启，这也是监控中要解决的问题，等等。看来监控真的是一项非常重要的工作。
通过上述描述，可以看出监控很重要。那具体的监控要如何开展呢？还要从实际的程序运行角度出发。比如现在有3个服务支撑着一个程序的运行，每个服务都有自己的运行状态。
此时被监控的信息就要在三个不同的程序中去查询并展示，但是三个服务是服务于一个程序的运行的，如果不能合并到一个平台上展示，监控工作量巨大，而且信息对称性差，要不停的在三个监控端查看数据。如果将业务放大成30个，300个，3000个呢？看来必须有一个单独的平台，将多个被监控的服务对应的监控指标信息汇总在一起，这样更利于监控工作的开展。
新的程序专门用来监控，新的问题就出现了，是被监控程序主动上报信息还是监控程序主动获取信息？如果监控程序不能主动获取信息，这就意味着监控程序有可能看到的是很久之前被监控程序上报的信息，万一被监控程序宕机了，监控程序就无法区分究竟是好久没法信息了，还是已经下线了。所以监控程序必须具有主动发起请求获取被监控服务信息的能力。
如果监控程序要监控服务时，主动获取对方的信息。那监控程序如何知道哪些程序被自己监控呢？不可能在监控程序中设置我监控谁，这样互联网上的所有程序岂不是都可以被监控到，这样的话信息安全将无法得到保障。合理的做法只能是在被监控程序启动时上报监控程序，告诉监控程序你可以监控我了。看来需要在被监控程序端做主动上报的操作，这就要求被监控程序中配置对应的监控程序是谁。
被监控程序可以提供各种各样的指标数据给监控程序看，但是每一个指标都代表着公司的机密信息，并不是所有的指标都可以给任何人看的，乃至运维人员，所以对被监控指标的是否开放出来给监控系统看，也需要做详细的设定。
以上描述的整个过程就是一个监控系统的基本流程。
总结
监控是一个非常重要的工作，是保障程序正常运行的基础手段
监控的过程通过一个监控程序进行，它汇总所有被监控的程序的信息集中统一展示
被监控程序需要主动上报自己被监控，同时要设置哪些指标被监控
思考
下面就要开始做监控了，新的问题就来了，监控程序怎么做呢？难道要自己写吗？肯定是不现实的，如何进行监控，咱们下节再讲。
6.2 可视化监控平台
springboot抽取了大部分监控系统的常用指标，提出了监控的总思想。然后就有好心的同志根据监控的总思想，制作了一个通用性很强的监控系统，因为是基于springboot监控的核心思想制作的，所以这个程序被命名为Spring Boot Admin。
Spring Boot Admin，这是一个开源社区项目，用于管理和监控SpringBoot应用程序。这个项目中包含有客户端和服务端两部分，而监控平台指的就是服务端。我们做的程序如果需要被监控，将我们做的程序制作成客户端，然后配置服务端地址后，服务端就可以通过HTTP请求的方式从客户端获取对应的信息，并通过UI界面展示对应信息。
下面就来开发这套监控程序，先制作服务端，服务端可以理解为是一个web程序，收到一些信息后展示这些信息。
6.2.1 服务端开发
步骤①：导入springboot admin对应的starter，版本与当前使用的springboot版本保持一致，并将其配置成web工程
de.codecentric
spring-boot-admin-starter-server
2.5.4
org.springframework.boot
spring-boot-starter-web
上述过程可以通过创建项目时使用勾选的形式完成。
步骤②：在引导类上添加注解@EnableAdminServer，声明当前应用启动后作为SpringBootAdmin的服务器使用
@SpringBootApplication
@EnableAdminServer
public class Springboot25AdminServerApplication {
public static void main(String[] args) {
SpringApplication.run(Springboot25AdminServerApplication.class, args);
}
}做到这里，这个服务器就开发好了，启动后就可以访问当前程序了，界面如下。
6.2.2 客户端开发
客户端程序开发其实和服务端开发思路基本相似，多了一些配置而已。
步骤①：导入springboot admin对应的starter，版本与当前使用的springboot版本保持一致，并将其配置成web工程
de.codecentric
spring-boot-admin-starter-client
2.5.4
org.springframework.boot
spring-boot-starter-web
上述过程也可以通过创建项目时使用勾选的形式完成，不过一定要小心，端口配置成不一样的，否则会冲突。
步骤②：设置当前客户端将信息上传到哪个服务器上，通过yml文件配置
spring:
boot:
admin:
client:
url: http://localhost:8080做到这里，这个客户端就可以启动了。启动后再次访问服务端程序，界面如下。
可以看到，当前监控了1个程序，点击进去查看详细信息。
由于当前没有设置开放哪些信息给监控服务器，所以目前看不到什么有效的信息。下面需要做两组配置就可以看到信息了。
开放指定信息给服务器看
允许服务器以HTTP请求的方式获取对应的信息
配置如下：
spring:
boot:
admin:
client:
#springbootadmin 服务器地址
url: http://localhost:8080
server:
port: 80
management:
endpoint:
health:
# 是否允许服务器读取health端点的数据（默认为never）
show-details: always
endpoints:
web:
exposure:
# 允许页面展示该项目的断电信息（默认只展示health）
include: "*"6.2.3 配置多个客户端
略
总结
开发监控服务端需要导入坐标，然后在引导类上添加注解@EnableAdminServer，并将其配置成web程序即可
开发被监控的客户端需要导入坐标，然后配置服务端服务器地址，并做开放指标的设定即可
在监控平台中可以查阅到各种各样被监控的指标，前提是客户端开放了被监控的指标
思考
之前说过，服务端要想监控客户端，需要主动的获取到对应信息并展示出来。但是目前我们并没有在客户端开发任何新的功能，但是服务端确可以获取监控信息，谁帮我们做的这些功能呢？咱们下一节再讲。
6.3 监控的原理
Actuator提供了SpringBoot生产就绪功能，通过端点的配置与访问，获取端点信息
端点描述了一组监控信息，SpringBoot提供了多个内置端点，也可以根据需要自定义端点信息
访问当前应用所有端点信息：/actuator
访问端点详细信息：/actuator/端点名称
Actuator，可以称为端点，描述了一组监控信息，SpringBootAdmin提供了多个内置端点，通过访问端点就可以获取对应的监控信息，也可以根据需要自定义端点信息。通过发送请求路劲/actuator可以访问应用所有端点信息，如果端点中还有明细信息可以发送请求/actuator/端点名称来获取详细信息。以下列出了所有端点信息说明：
ID |
描述 |
默认启用 |
auditevents |
暴露当前应用程序的审计事件信息。 |
是 |
beans |
显示应用程序中所有 Spring bean 的完整列表。 |
是 |
caches |
暴露可用的缓存。 |
是 |
conditions |
显示在配置和自动配置类上评估的条件以及它们匹配或不匹配的原因。 |
是 |
configprops |
显示所有 @ConfigurationProperties 的校对清单。 |
是 |
env |
暴露 Spring ConfigurableEnvironment 中的属性。 |
是 |
flyway |
显示已应用的 Flyway 数据库迁移。 |
是 |
health |
显示应用程序健康信息 |
是 |
httptrace |
显示 HTTP 追踪信息（默认情况下，最后 100 个 HTTP 请求/响应交换）。 |
是 |
info |
显示应用程序信息。 |
是 |
integrationgraph |
显示 Spring Integration 图。 |
是 |
loggers |
显示和修改应用程序中日志记录器的配置。 |
是 |
liquibase |
显示已应用的 Liquibase 数据库迁移。 |
是 |
metrics |
显示当前应用程序的指标度量信息。 |
是 |
mappings |
显示所有 @RequestMapping 路径的整理清单。 |
是 |
scheduledtasks |
显示应用程序中的调度任务。 |
是 |
sessions |
允许从 Spring Session 支持的会话存储中检索和删除用户会话。当使用 Spring Session 的响应式 Web 应用程序支持时不可用。 |
是 |
shutdown |
正常关闭应用程序。 |
否 |
threaddump |
执行线程 dump。 |
是 |
heapdump |
返回一个 hprof 堆 dump 文件。 |
是 |
jolokia |
通过 HTTP 暴露 JMX bean（当 Jolokia 在 classpath 上时，不适用于 WebFlux）。 |
是 |
logfile |
返回日志文件的内容（如果已设置 logging.file 或 logging.path 属性）。支持使用 HTTP Range 头来检索部分日志文件的内容。 |
是 |
prometheus |
以可以由 Prometheus 服务器抓取的格式暴露指标。 |
是 |
上述端点每一项代表被监控的指标，如果对外开放则监控平台可以查询到对应的端点信息，如果未开放则无法查询对应的端点信息。通过配置可以设置端点是否对外开放功能。使用enable属性控制端点是否对外开放。其中health端点为默认端点，不能关闭。
# 启用指定端点
management:
endpoint:
health: # 端点名称
show-details: always
info: # 端点名称
enabled: true # 是否开放为了方便开发者快速配置端点，springboot admin设置了13个较为常用的端点作为默认开放的端点，如果需要控制默认开放的端点的开放状态，可以通过配置设置，如下：
# 启用所有短点
management:
endpoints:
enabled-by-default: true # 是否开启默认端点，默认值true上述端点开启后，就可以通过端点对应的路径查看对应的信息了。但是此时还不能通过HTTP请求查询此信息，还需要开启通过HTTP请求查询的端点名称，使用“*”可以简化配置成开放所有端点的WEB端HTTP请求权限。
# 允许在Web端展示的端点信息
management:
endpoints:
web:
exposure:
include: "*" # 展示所有已开启的端点数据整体上来说，对于端点的配置有两组信息，一组是endpoints开头的，对所有端点进行配置，一组是endpoint开头的，对具体端点进行配置。
management:
endpoint: # 具体端点的配置
health:
show-details: always
info:
enabled: true
endpoints: # 全部端点的配置
web:
exposure:
include: "*"
enabled-by-default: true总结
被监控客户端通过添加actuator的坐标可以对外提供被访问的端点功能
端点功能的开放与关闭可以通过配置进行控制
web端默认无法获取所有端点信息，通过配置开放端点功能