SpringCloud 狂神说 学习笔记

微服务架构4个核心问题?(从问题入手)

1.服务很多,客户端该怎么访问?
2.这么多服务?服务之间如何通信?
3.这么多服务? 如何治理?
4.服务挂了怎么办?
SpringCloud是生态 是一个解决方案 例如小米公司的生态
1.Spring cloud NetFlix
2.Apache Dubbo Zookeeper
3.Spring cloud Alibaba
解决以上四个核心问题
在这里插入图片描述

图 SpringCloud NetFlix 本文档主要学习这套解决方案

在这里插入图片描述

图 Apache Dubbo Zookeeper 这是另一套解决方案 在SSM中非常常见

微服务优缺点

优点
1.单一职责原则
2.每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定的业务功能或业务需求;
3.开发简单,开发效率提高,一个服务可能就是专一的只干一件事;
4.微服务能够被小团队单独开发,这个小团队是2-5人的开发人员组成;
5.微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
6.微服务能使用不同的语言开发。
7.易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如jenkins, Hudson,bamboo
8.微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
9.微服务允许你利用融合最新技术。
10.微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面混合
11.每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一数据库

SpringCloud

在这里插入图片描述

图 SpringCloud图解

在这里插入图片描述

图 SpringBoot图解

SpringBoot和SpirngCloud的区别

在这里插入图片描述

图 SpringCloud和SpringBoot区别

开始学习SpringCloud-Netflix

课外知识:Netflix(Nasdaq NFLX) 成立于1997年,是一家在线影片租赁提供商,主要提供Netflix超大数量的DVD并免费递送,总部位于美国加利福尼亚州洛斯盖图。(不正经的卖碟公司-搞技术)

Eureka (服务注册与发现)

基于CS架构 遵循AP原则
Eureka是Ntflix的一个子模块,也是核心模块之一。Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移,服务注册与发现对于微服务来说是非常重要的,有了服务发现与注册,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了,功能类似于Zookeeper
在这里插入图片描述

图 Eureka图解

Eureka 自我保护机制:

某时刻某一个微服务不可以用了,eruka不会立即清理,依旧会对该微服务信息进行保存!
在SpringCloud中,可以使用‘eureka. server.enable-self-preservation = false’ 禁用自我保护模式[不推荐关闭自我保护机制]

Eureka配置详解(开发工具IDEA 以下环境不再重复)

在这里插入图片描述

图 实体类配置(模块化后其他模块需要引用实体类)

在这里插入图片描述

图 服务端pom.xml配置(需要导入eureka-server,gson,web)

在这里插入图片描述

图 服务端applicaton.yml配置(fetch-registry为false证明自己是注册中心)

在这里插入图片描述

图 启动类配置(加@EnableEurekaServer注解)

Eureka提供者配置

在这里插入图片描述

图 提供者pom.xml配置(Eureka、gson)

在这里插入图片描述

图 提供者application.yml配置(向服务端注册)

在这里插入图片描述

图 提供者启动类(@EnableEurekaClient)

在这里插入图片描述

图 获取服务信息 多人开发使用(做了解,但是该功能需要在启动类加@EnableDiscoveryClient)

Eureka消费者配置

消费者和前端打交道,所以pom.xml只需要配置实体类和web
在这里插入图片描述

图 配置RestTemplate(因为Eureka基于Rest开发)

在这里插入图片描述

图 消费者Controller调用方式(通过一个Rest地址请求)

Eureka集群配置

在这里插入图片描述

图 集群例图(7001,7002,7003皆为Eureka服务端)

配置实例
注册中心
在这里插入图片描述

图 注册中心(关联其他两个Eureka服务端)

提供者 在这里插入图片描述

图 提供者(向三个服务器端进行注册)

对比Zookeeper(理论知识)

回顾CAP原则
RDBMS关系型数据库 (Mysq|、Oracle、sqlServer) ===>ACID
NoSQL 非关系型数据库(redis、mongdb) ===> CAP

ACID是什么?

1.A (Atomicity) 原子性
2.C(Consistency)一致性
3.I(Isolation) 隔离性
4.D (Durability) 持久性

CAP是什么?

1.C (Consistency) 强一致性
2.A (Availability) 可用性
3.P (Partition tolerance) 分区容错性

CAP原则又称CAP定理,指的是在一个分布式系统中,一致性 (Consistency)、可用性(Availability) 、分区容错性(Partition tolerance)。CAP原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
CAP的三进二: CA、AP、CP

CAP理论的核心

1.一个分布式系统不可能同时很好的满足一致性可用性分区容错性这三个需求
2.根据CAP原理,将NoSQL数据库分成了满足CA原则,满足CP原则和满足AP原则三大类:
①CA:单点集群,满足一致性,可用性的系统,通常可扩展性较差
②CP:满足一致性,分区容错性的系统,通常性能不是特别高
③AP:满足可用性,分区容错性的系统,通常可能对一致性要求低一些
作为服务注册中心,Eureka比Zookeeper好在哪里?
著名的CAP理论指出,一个分布式系统不可能同时满足C (一致性)、A (可用性)、P (容错性)。由于分区容错性P在分布式系统中是必须要保证的,因此我们只能在A和C之间进行权衡。
Zookeeper保证的是CP;Eureka保证的是AP;

Zookeeper保证的是CP

当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30~120s,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因为网络问题使得zk集群失去master’节点是较大概率会发生的事件,虽然服务最终能够恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点, 因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在, 就能保住注册服务的可用性,只不过查到的信息可能不是最新的,除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(即保证当前节点依然可用)
3.当网络稳定时,当前实例新的注册信息会被同步到其他节点中
因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪

Ribbon

1.Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具
2.简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如: 连接超时重试等等。简单的说,就是在配置文件中列出LoadBalancer (简称LB:负载均衡)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等等可以自定义)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法!

Ribbon的作用

1.LB,即负载均衡(Load Balance),在微服务或分布式集群中经常用的一种应用。
2.负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA (高可用)。
3.常见的负载均衡软件有Nginx(安装之后写配置), Lvs(国内大神写)等等
4.dubbo、SpringCloud中均给我们提供了负载均衡,SpringCloud的负载均衡算法可以自定义
5.负载均衡简单分类:
①集中式LB
■即在服务的消费方和提供方之间使用独立的LB设施,如Nginx: 反向代理服务器!由该设施负责把访问请求通过某种策略转发至服务的提供方! (由服务端进行调度)
②进程式LB
■将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选出一个合适的服务器。(由客户端进行调度)
Ribbon就属于进程内LB,它只是一个类库,集成于消费方进程,消费方通过它来获取到服务提供方的地址!

Ribbon配置

Ribbon是在客户端实现的,所以在消费者这端进行配置

在这里插入图片描述

图 消费者pom.xml(ribbon,eureka,gson,httpclient,箭头表示jar包之间互相的依赖)

在这里插入图片描述

图 消费者applicaton.yml(和之前配置一样)

在这里插入图片描述

图 消费者ConfigBean(在RestTemplate上面加注释@LoadBalanced)

在这里插入图片描述

图 消费者启动类(和之前配置一样)

在这里插入图片描述

图 在消费者Controller修改了原有的调用地址(直接通过定义在Eureka中注册的APP名字直接注册)

Ribbon和Eureka整合之后,客户端可以直接调用,不用关心IP地址
通过创建三个不同端口号的提供者来测试,三个提供者拥有三个数据库,唯一的区别就是datasource不一样,经过测试,Ribbon负载均衡,每次访问就会读取不同提供者的数据库。

自定义Ribbon 负载均衡算法

在这里插入图片描述

图 负载均衡算法(自定义算法替换Ribbon自带随机轮询算法)

在这里插入图片描述

图 轮询算法(根据随机轮询算法更改核心代码)

在这里插入图片描述

图 通过在启动列添加@RibbonClient指向自定义的类将Ribbon自带的算法取代

Feign 声明性Rest客户端

简介(理论知识):
feign是声明式的web service客户端,它让微服务之间的调用变得更简单了,类似controller调用service。SpringCloud集成了Ribbon和Eureka,可在使用Feign时提供负载均衡的http客户端。(只需要创建一个接口,然后添加注解即可)
Feign,大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法
1.微服务名字[ribbon]
2.接口和注解[feign]

Feign能干什么?

●Feign旨在使编写Java Http客户端变得更容易
●前面在使用Ribbon + RestTemplate时,利用RestTemplate对Http请求的封装处理,形成了一套模板化的调用方法。但是在实际开发中,由于对服务依赖的调用可能不止一处,往往一个接口会被多处调用,所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以,Feign在此基础上做了进一步封装,由他来帮助我们定义和实现依赖服务接口的定义,在Feign的实现下,我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解,现在是一个微服务接口上面标注一个Feign注解即可。) 即可完成对服务提供方的接口绑定,简化了使用Spring Cloud Ribbon时,自动封装服务调用客户端的开发量。

Feign集成了Ribbon

●利用Ribbon维护了服务列表信息,并且通过轮询实现了客户端的负载均衡,而与Ribbon不同的是,通过Feign只需要定义服务绑定接口且以声明式的方法,优雅而且简单的实现了服务调用。
Feign也可结合Hystirx

Feign配置

在这里插入图片描述

图 这是api模块中service包 供公共调用,记得加@FeignClinet和@component(注册到Spring容器中)注解(使用RestTemplate不用新创建包,但是这个需在API模块创建包并供调用)

在这里插入图片描述

图 api模块和消费者模块导入feign jar包

在这里插入图片描述

图 消费者application.yml(和之前配置一样 没改变 只要向Eureka注册自己)

在这里插入图片描述

图 消费者Controller修改原有Ribbon调用方式 注入之后直接使用Java面向对象接口调用

在这里插入图片描述

图 消费者主启动类配置FeignClient的扫描注解包

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免的失败!

服务雪崩

多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的“扇出”、如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”。
对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障,这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。我们需要:弃车保帅.

Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时,异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。

断路器

“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个服务预期的,可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方法无法处理的异常,这样就可以保证了服务调用方的线程不会被长时间,不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩.
功能
●服务降级
●服务熔断
●服务限流
●接近实时的监控

服务熔断

熔断机制是对应雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

服务熔断配置 (在提供者里配置)

在这里插入图片描述

图 提供者pom.xml(加入hystrix依赖)

在这里插入图片描述

图 修改消费者controller调用方式 使用@HystrixCommand注解指向出错时要调用的方法(缺点就是每个controller方法都会需要有一个备选方案)

在这里插入图片描述

图 在消费者启动类中加入开启对熔断的支持(@EnableCircuitBreaker)经过测试,不加熔断机制的出现异常会直接出现500错误,而加入的Hystrix熔断机制的出现异常时会跳到备选方案直接返回结果,等服务不崩溃了再返回正常

服务降级(在客户端实现)

用于对关闭某些服务器来实现特殊需要功能时采用 这样访问原来服务器就不会出现404报错

什么是服务降级?

当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。(弃车保帅)
如果还是不理解,那么可以举个例子:假如目前有很多人想要给我付钱,但我的服务器除了正在运行支付的服务之外,还有一些其它的服务在运行,比如搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的不少内存与CPU资源,为了能把钱都收下来(钱才是目标),我设计了一个动态开关,把这些不重要的服务直接在最外层拒掉,这样处理后的后端处理收钱的服务就有更多的资源来收钱了(收钱速度更快了),这就是一个简单的服务降级的使用场景。

服务降级配置

在这里插入图片描述

图 在api模块中创建降级类,并实现FallbackFactory接口重写create方法(修改返回值类型<原来是object>直接对类处理)

在这里插入图片描述

图 在api模块被处理的Feign接口中添加fallbackFactory属性(Feign整合了Hystrix)

在这里插入图片描述

图 在feign消费端application.yml中配置降级

Hystrix:Dashboard流监控

(用来监控实例的健康程度)因为在客户端监控 所以配在消费者端口
配置
在这里插入图片描述

图 提供者必须导入actuator包 这个监控信息 否则得不到dashboard的信息

在这里插入图片描述

图 消费者需要导入 hystirx、hystrix-dashboard、jackson包

在这里插入图片描述

图 消费者端application.yml配一个端口

在这里插入图片描述

图 消费者启动类需要加@EnableHystirxDashboard开启Hystrix-Dashboard

在这里插入图片描述

图 在提供者启动类上加上监控Servlet请求

在这里插入图片描述

图 Hystirx-dashboard效果图

Zuul路由网关

Zuul包含了对请求的路由过滤两个最主要的功能:
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础,而**过滤器功能则负责对请求的处理过程进行干预,**是实现请求校验,服务聚合等功能的基础。Zuul和Eureka进行整合, 将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul跳转后获得
注意: Zuu|服务最终还是会注册进Eureka
提供:代理+路由+过滤三大功能!
在这里插入图片描述

图 Zuul网关图解

Zuul网关配置

在这里插入图片描述

图 导入zuul和eureka依赖(zuul需要注册到eureka中)

在这里插入图片描述

图 在yml中配置zuul 注册进Eureka中 配置路径

在这里插入图片描述

图 在启动类中加入@EnableZuulProxy 开启Zuul网关

在这里插入图片描述

图 实际效果

SpringCloud config 分布式配置

分布式系统面临的配置文件的问题
微服务意味着要将单体应用中的业务拆分成一个个子服务, 每个服务的粒度相对较小,因此系统中会出现大量的服务,由于每个服务都需要必要的配置信息才能运行,所以一套集中式的, 动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,那上百的的配置文件要修改起来,岂不是要发疯!
在这里插入图片描述

图 SpringCloud config配置中心图解

Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。
Spring Cloud Config 分为服务端客户端两部分;
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密,解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

SpringCloud config分布式配置中心能干嘛

●集中管理配置文件
●不同环境,不同配置,动态化的配置更新,分环境部署,比如/dev /test/ /prod /beta /release
●运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息。
●当配置发生变动时,服务不需要重启,即可感知到配置的变化,并应用新的配置
●将配置信息以REST接口的形式暴露
SpringCloud config分布式配置中心与github整合
由于Spring Cloud Config默认使用Git来存储配置文件(也有其他方式,比如支持SVN和本地文件), 但是最推荐的还是Git,而且使用的是http / https访问的形式;

Config-Server服务端配置(典型SpringBoot配置)

1.导入jar包
2.配置yml
3.加注解启动
在这里插入图片描述

图 pom.xml配置(导入config-server)

在这里插入图片描述

图application.yml配置 配置远程项目地址

在这里插入图片描述

图 git上yml配置信息(application.yml配置多文档配置环境)

图 启动类开启ConfigServer(加入注解@EnableConfigServer)

图 启动类开启ConfigServer(加入注解@EnableConfigServer)

在这里插入图片描述

图 效果

Config-Server客户端配置

在这里插入图片描述

图 与服务端不同的包 starter-config

在这里插入图片描述

图 配置bootstrap.yml(系统级别的配置,和application.yml不同 这个配置的就是从哪个地方获取配置信息)

在这里插入图片描述

图 git项目上的配置文件

在这里插入图片描述

图 测试controller直接通过@value获取服务端的配置信息

在这里插入图片描述

图 客户端启动类

在这里插入图片描述

图 测试效果(从服务端获取的信息)

ConfigServer实战概述(整合原来Eureka7001和Provider8001)

1.在远程配置项目上写eureka配置信息
2.创建一个eureka项目,导入config-server jar包,写一个bootstrap.yml 里面写配置要从哪个地方获取
3.启动项目
4.和上1,2,3步骤一样再配置provider的配置信息
5.两个都启动后则可从云端获取配置信息

实战配置

Config服务端
在这里插入图片描述

图 服务端导入config-server配置

在这里插入图片描述

图 服务端yml图 uri后面格式最好不要用注释

在这里插入图片描述

图 服务端开启注解启动项目

重构Eureka

在这里插入图片描述

图 重构eureka-7001项目 导入starter-config包

在这里插入图片描述

图 配置bootstrap.yml配置 label是远端git分支 profile是环境,这里指定之后优先级大于远程

在这里插入图片描述

图 启动类不需要加config注解

Provider项目重构
在这里插入图片描述

图 同理 重构provider项目 导入starter-config jar包

在这里插入图片描述

图 配置provider的bootstrap.yml

在这里插入图片描述

图 启动类一样不需要加注解

因为项目配置github地址可能会出现连接超时异常 这个跟你所在网段和GitHub上网络有关 这个很怪 一会好一会坏
成功的话 可以在eureka没有配置的情况下启动7001 和provider没有配置的情况下启动8001 可以根据github上配置信息的改变来获取不同数据源

SpringCloud总结图示

在这里插入图片描述

图 SpringCloud总结

源码链接:SpringCloud-NetFilx自写源码

  • 7
    点赞
  • 43
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
整理自尚硅谷视频教程springboot高级篇,并增加部分springboot2.x的内容 一、Spring Boot与缓存 一、JSR107 Java Caching定义了5个核心接口,分别是CachingProvider, CacheManager, Cache, Entry 和 Expiry。 • CachingProvider定义了创建、配置、获取、管理和控制多个CacheManager。一个应用可 以在运行 期访问多个CachingProvider。 • CacheManager定义了创建、配置、获取、管理和控制多个唯一命名 的Cache,这些Cache 存在于CacheManager的上下文中。一个CacheManager仅被一个 CachingProvider所拥有。 • Cache是一个类似Map的数据结构并临时存储以Key为索引的值。一个 Cache仅被一个 CacheManager所拥有。 • Entry是一个存储在Cache中的key-value对。 • Expiry 每一 个存储在Cache中的条目有一个定义的有效期。一旦超过这个时间,条目为过期 的状态。一旦过期,条 目将不可访问、更新和删除。缓存有效期可以通过ExpiryPolicy设置。 二、Spring缓存抽象 Spring从3.1开始定义了org.springframework.cache.Cache 和 org.springframework.cache.CacheManager接口来统一不同的缓存技术; 并支持使用JCache(JSR- 107)注解简化我们开发; • Cache接口为缓存的组件规范定义,包含缓存的各种操作集合; • Cache接 口下Spring提供了各种xxxCache的实现;如RedisCache,EhCacheCache , ConcurrentMapCache 等; • 每次调用需要缓存功能的方法时,Spring会检查检查指定参数的指定的目标方法是否 已经被调用 过;如果有就直接从缓存中获取方法调用后的结果,如果没有就调用方法 并缓存结果后返回给用户。下 次调用直接从缓存中获取。 • 使用Spring缓存抽象时我们需要关注以下两点; 1、确定方法需要被缓存 以及他们的缓存策略 2、从缓存中读取之前缓存存储的数据 Cache 缓存接口,定义缓存操作。实现有:RedisCache、EhCacheCache、 ConcurrentMapCache等 CacheManager 缓存管理器,管理各种缓存(Cache)组件 @Cacheable 主要针对方法配置,能够根据方法的请求参数对其结果进行缓存 @CacheEvict 清空缓存 @CachePut 保证方法被调用,又希望结果被缓存。 @EnableCaching 开启基于注解的缓存 keyGenerator 缓存数据时key生成策略 serialize 缓存数据时value序列化策略 @CacheConfig 抽取缓存的公共配置 三、几个重要概念&缓存注解 1、常用注解 2、常用参数 名字 位置 描述 示例 methodName root object 当前被调用的方法名 #root.methodName method root object 当前被调用的方法 #root.method.name target root object 当前被调用的目标对象 #root.target targetClass root object 当前被调用的目标对象类 #root.targetClass args root object 当前被调用的方法的参数列表 #root.args[0] 3、常用参数SPEL明 名字 位置 描述 示例 caches root object 当前方法调用使用的缓存列表(如 @Cacheable(value= {"cache1","cache2"}) ), 则有两 个cache #root.caches[0].name argument name evaluation context 方法参数的名字. 可以直接 #参数 名 ,也可以使用 #p0或#a0 的形 式,0代表参数的索引; #iban 、 #a0 、 #p0 result evaluation context 方法执行后的返回值(仅当方法执 行之后的判断有效,如‘unless’ , ’cache put’的表达式 ’cache evict’的表达式 beforeInvocation=false ) #result 四、代码中使用缓存 1、搭建基本环境 1、导入数据库文件 创建出department和employee表 2、创建javaBean封装数据 3、整合MyBatis操作数据库 1.配置数据源信息 2.使用注解版的MyBatis; 1)、@MapperScan指定需要扫描的mapper接口所在的包
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值