先别看 我这里是瞎写的

**

Java对象的4种引用类型==========================================

**

强引用：
----强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。 ps：强引用其实也就是我们平时A a = new A()这个意思。

软引用：
----被软引用的对象，如果内存空间足够，垃圾回收器是不会回收它的，如果内存空间不足，垃圾回收器将回收这些对象占用的内存空间。软件引用对应着java.lang.ref.SoftReference类，一个对象如果要被软引用，只需将其作为参数传入SoftReference类的构造方法中就行了。感觉还是比较简单而且容易理解。

弱引用：
----与前面的软引用相比，被弱引用了的对象拥有更短的内存时间（也就是生命周期）。垃圾回收器一旦发现了被弱引用的对象，不管当前内存空间是不是足够，都会回收它的内存，弱引用对应着java.lang.ref.WeakReference类，同样的道理。一个对象如果想被弱引用，只需将其作为参数传入WeakReference类的构造方法中就行了。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

虚引用:
----“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。

**

事务相关====================================================

**

事务特性
原子性。事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
一致性。事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
隔离性。一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
持续性。也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响

如果不考虑隔离性，会引发下面的问题
事务在操作最理想的状态就是,所有事务之间保持隔离,但是当多个用户同时访问同一个数据的时候,可能会出现并发访问的问题
都是因为另一个事务的操作,干扰了我当前事务的操作
**1: 脏读:**当前事务读取到另一个事务中还没提交的数据,造成了数据脏读
**2: 不可重复度:**另一个事务执行了update更新操作,使当前事务在两次读取数据时,内容不一致,造成了不可重复读
**3: 幻读:**另一个事务进行插入数据,或者删除数据,使当前事务两次读取的数据数量不一致,造成了数据幻读

可以通过设置事物隔离级别解决读的问题
事务的隔离级别
1: 读未提交：
未解决
最低的隔离级别,脏读,不可重复读,幻读,他都有可能读到

2: 读已提交：
解决 脏读
他读不到未提交的,只读已提交的,所以他可以避免脏读,但是你读已提交的就可能读到不一样的内容,所以不可重复读和幻读还是有可能出现的.

3:可重复读：
解决 脏读 不可重复度
听名字就知道是解决了不可重复读,查询的都是事务开始时的数据,但是解决不了幻读。

4: 串行读：
解决 脏读 不可重复度
幻读最高级别, 完全串行化读，每次都会锁表,读写互相阻塞。

MySQL的默认级别就是可重复度 / 隔离级别越高，安全性越高，性能(效率)越差。

事物的原理:

1: 客户端连接数据库,只要一连接就会开启一个临时事务日志,
2: 如果直接写SQL语句操作数据库,他会把执行的数据直接同步到数据库,因为MySQL是默认开启自动事务,这就是为什么我们一执行SQL语句数据库就会变化.
3: 如果是我们手动开启事务,数据库服务器就会创建一个临时日志文件,
4: 之后执行SQL语句,他会把结果写在临时日志文件当中,并没有修改到数据库,所以如果不提交事务的话,你是看不到结果的,所以当你commit提交事务后,数据库服务器就会将临时日志文件中刚才执行的结果提交到数据库,你才能看到结果,
5: 但是如果你是用的是rollback回滚,他就会把这个结果从临时日志文件中给删掉,然后这个事务就结束了,所以回滚只是将临时日志文件中的数据删除,在这之前并没有关系到数据库本身,所以数据库没有发生变化.

**

Redis相关==================================================

**
是一种高性能的key-value非关系型数据库。

Redis的所有操作都是原子性的,支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis存储的数据是键值对的形式:
1: String 字符串，最简单的k-v存储，短信验证码，配置信息 / 等，就用这种类型来存储。
2: Hash 数据结构就是HashMap里面套一个HashMap, 适合存储对象,我们一般用它存储用户信息对象之类的
3: List 列表有序 比较适合存储有序切固定的数据,他还可以做为队列适用,使用左插右取的方式,适用于广告类存储,元素不唯一
4: Set无序集合 他类似于List,不一样的是Set可以对数据进行一个交集并集差集的运算,使用抽奖啊,共同好友统计之类的
5: Zset有序集合,Set的增强版,增加了一个score参数,自动会根据score值进行排序,使用有排序的数据,班级成绩,销量排名,名次排名之类的

作用:
1.缓存(对经常查询的数据缓存到Redis中,减轻对mysql的压力)
2.任务队列(例如抢购之类的)
3.数据过期处理(可以精确到毫秒,例如短信验证码)
4.会话Session存储

Redis的持久化:
分为两种:
1: RDB持久化机制:他是以指定时间间隔内去将内存中的数据快照方式写入磁盘,以二进制文件存储,这个是默认的方式,安全性低由于间隔持久化,可能出现数据丢失.他在回复大数据集时速度比AOF快,因为文件比AOF小
2: AOF持久化机制:他是以每执行一次的方式去持久化一次,所以他的保存的数据是最完整的,速度相对RDB可能会慢些,安全性高。即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题
如何选择:
1: 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，选择RDB 持久化。
2: 如果对数据的完整性要求比较高, 选择AOF 持久化

Redis各种问题现象:

Redis缓存穿透
现象描述：是指查询一个数据库一定不存在的数据。(都没有数据)
1、数据查询首先进行缓存查询 id=1setmealDetail_id = null
2、如果数据存在则直接返回缓存数据
3、如果数据不存在，就对数据库进行查询，并把查询到的数据放进缓存 1 null
4、如果数据库查询数据为空，则不放进缓存
例如我们的数据表中主键是自增产生的，所有的主键值都大于0。此时如果用户传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。程序就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有人恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮我们的数据库。
解决方案： 为了防止有人利用这个漏洞恶意攻击我们的数据库，我们可以采取如下措施：
如果从数据库查询的对象为空，也放入缓存，key为用户提交过来的主键值，value为null，只是设定的缓存过期时间较短，比如设置为60秒。这样下次用户再根据这个key查询redis缓存就可以查询到值了（当然值为null），从而保护我们的数据库免遭攻击。到期就消失为了以后有真的有数据也要返回真实数据
如用户鉴权校验，id做基础校验，id<=0的直接拦截；

Redis缓存击穿(数据库有数据)
现象描述：缓存击穿，是指一个key非常热点（例如双十一期间进行抢购的商品数据），在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求到数据库上，就像在一个屏障上凿开了一个洞。
解决方案：我们同样可以将这些热点数据设置永不过期就可以解决缓存击穿的问题了。或者阶段性的延长过期时间
加互斥锁(mutex key)。简单来讲，就是要操作db，需要排队

Redis缓存雪崩
现象描述： 缓存雪崩，是指在某一个时间段，缓存集中过期失效。在缓存集中失效的这个时间段对数据的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。
解决方案： 为了避免缓存雪崩的发生，我们可以将缓存的数据设置不同的失效时间，这样就可以避免缓存数据在某个时间段集中失效。例如对于热门的数据（访问频率高的数据）可以缓存的时间长一些，对于冷门的数据可以缓存的时间短一些。甚至对于一些特别热门的数据可以设置永不过期(内存的开销)。
1.
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2.
一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。
3.
给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

Redis缓存降级问题
现象描述：当访问量剧增、服务出现问题（如响应时间慢或不响应）,仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

1. 服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

缓存降级的最终目的是保证核心服务可用，即使是有损的

Redis中过期键的删除策略

Redis中同时使用了惰性过期和定期过期两种过期策略。

常见有3种过期策略，定期过期，定时过期，惰性过期。
1: 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
2: 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。
3: 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

定期、定时，是主动删除。惰性，是被动删除

Redis的缓存淘汰机制
当redis内存快耗尽时，redis会启动内存淘汰机制，将部分key清掉以腾出内存

大致分为4种 / 具体差不多有9种吧
1: 从设置了过期时间选最近最少使用的
2: 从设置了过期时间选快被淘汰的
3: 从设置了过期时间随机挑选
4: 没设置时间选最近最少使用的
5: 没设置时间随机挑选

主从复制( 读写分离)
1: 主从复制就是我们常见的master/slave模式，通常一主多从。
2: 可以实现读写分离，Master具有读写权限，Slave只有读权限。
3: 可以实现容灾备份，配合哨兵机制。
4: 搭建也很简单，主结点不用改，从结点简单配置后,指向主结点的ip和端口就可以。

官方推荐Redis高可用性(HA)的两个解决方案
1: Redis哨兵机制Redis-Sentinel

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务

----1:监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常
----2:提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
----3:自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master,保证了数据的统一性。

2: Redis-Cluster内置集群:
建议:不要超过200个节点,平通命令造成网路带宽的瓶颈过高,

Redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

它存储数据是以哈希槽的方式去存储的就是说,默认分配了16384个哈希槽,假如现在有三个节点,A/B/C,会将16384个哈希

槽平分给这三个节点分别是
节点A覆盖0－5460:
节点B覆盖5461－10922
节点C覆盖10923－16383(从零开始)

他存数据时,先将数据的key值使用哈希算法CRC16然后在取模16384他的哈希槽数,然后根据取模后的值,分配到对应的节点中

**

数据库相关==================================================

**

Canal原理相对比较简单：
canal模拟mysql slave从节点的交互协议，伪装自己为mysql slave从节点，向mysql master主机发送dump协议mysql master收到dump请求，开始推送binary log给slave(也就是canal)canal解析binary log对象(原始为byte流)虚拟机有主从模式,默认是关闭的单机模式 , Canal伪装成他的从服务器获取他的每一部操作
mysql默认不开启主从模式,所以需要手动开启(binlog)
再给Canal给个登录的账号

**

Spring相关==================================================

**
谈谈自己对于 Spring IoC 和 AOP 的理解

AOP:
aop是面向切面编程，oop是面向对象编程，主要就是在不修改源码的基础上，对我们的已有方法进行增强,就是所谓的动态代理

aop采用的是横向抽取机制，取代了传统的纵向继承体系，就是说如果不使用这个动态代理来实现对方法的增强的话,如果有100个方法需要增强你就需要写100次,那这个AOP呢就是底层封装了动态代理模式,采用横向抽取机制,减少了代码的重复冗余,

它使用的有两个动态代理, JDK的动态代理 / CgLib的动态代理
我们主要使用AOP来做：
1:事务处理：执行方法前：开始事务、执行完成后关闭事务、出现异常后回滚事务
2:权限判断：执行方法前，判断是否具有权限
3:日志： 在执行前进行日志处理
4:等等

IOC:(容器)(控制反转)
ioc容器实际上就是个map（key，value），里面存的是各种对象（在xml里配置的bean节点||repository、service、controller、component），在项目启动的时候会读取配置文件里面的bean节点，根据全限定类名使用反射new对象放到map里；扫描到打上上述注解的类还是通过反射new对象放到map里。
这个时候map里就有各种对象了，接下来我们在代码里需要用到里面的对象时，再通过DI注入（autowired、resource等注解，xml里bean节点内的ref属性，项目启动的时候会读取xml节点ref属性根据id注入，也会扫描这些注解，根据类型或id注入；id就是对象名）。
至于为什么要这么做，要知道工厂模式（控制反转）解决了什么问题又带来了什么问题。
1.解决的问题：解决了类与类之间强引用关系的问题，强引用关系导致了代码的耦合性高，维护性差。（控制反转的作用，举个例子，现在有个变量String name=“小明”，在两个类里都要用到小明这个字符串，如果不使用控制反转，在class A中要定义一个String name=“小明”；在class B中也要定义一个String name=“小明”；这个时候我需要把小明改成李四，那我需要找到所有用到“小明”的类然后一个一个去修改。实际上我们是定义一个静态常量，然后在需要用到的地方进行引用，这样的话当我们需要把小明修改成李四只需要去定义这个静态常量的那个类里去修改一次，所有引用到的地方都被修改了。这其实就是控制反转，定义静态常量的类就是工厂类，被定义的常量就是ioc容器内的各种对象）

DI:(注入)
DI注入（autowired、resource等注解，xml里bean节点内的ref属性，项目启动的时候会读取xml节点ref属性根据id注入，也会扫描这些注解，根据类型或id注入；id就是对象名）。

循环依赖:
循环依赖就是说:===是一个或多个对象实例之间存在直接或间接的依赖关系，这种依赖关系构成了构成一个环形调用.比如A的创建需要B,但B的创建又需要A,这种关系.

spring是如何解决循环依赖的

它的大致过程是这样的：
1: 首先A对象实例化，然后对属性进行注入，发现依赖B对象
2: B对象此时还没创建出来，所以转头去实例化B对象
3: B对象实例化之后，发现需要依赖A对象，那A对象已经实例化了嘛，所以B对象最终能完成创建
4: B对象返回到A对象的属性注入的方法上，A对象最终完成创建

至于原理，其实就是用到了三级的缓存

所谓的三级缓存其实就是三个Map…首先明确一定，我对这里的三级缓存定义是这样的：
singletonObjects（一级，日常实际获取Bean的地方）；
earlySingletonObjects（二级，还没进行属性注入，由三级缓存放进来）；
singletonFactories（三级，Value是一个对象工厂）；

再回到刚才讲述的过程中，
1: A对象实例化之后，属性注入之前，其实会把A对象放入三级缓存中
2: key是BeanName，Value是ObjectFactory
3: 等到A对象属性注入时，发现依赖B，又去实例化B时
4: B属性注入需要获取A对象,这里就是从三级缓存里拿出ObjectFactory,从ObjectFactory得到对应的Bean(就是对象A)
5: 把三级缓存的A记录给干掉，然后放到二级缓存中
6: 显然，二级缓存存储的key是BeanName，value就是Bean（这里的Bean还没做完属性注入相关的工作）
7: 等到完全初始化之后，就会把二级缓存给remove掉，塞到一级缓存中
8: 我们自己去getBean的时候，实际上拿到的是一级缓存的
大致的过程就是这样

Bean生命周期

普通Java对象和Spring所管理的Bean实例化的过程是有些区别的
在普通Java环境下创建对象简要的步骤可以分为：
1: java源码被编译为被编译为class文件
2: 等到类需要被初始化时（比如说new、反射等）
3: class文件被虚拟机通过类加载器加载到JVM
4: 初始化对象供我们使用

Bean作用域

**

SpringBoot相关==============================================

**

起步依赖：
起步依赖主要针对的是pom文件，优化了之前要写大量的坐标，还要指定版本号，
**1：**pom文件中写一个父工程Springboot-starter-prant他是起步依赖的第一步，通过父工程的依赖进去可以发现它里面还有跟多的依赖，它定义了所有你可能使用到的坐标版本号，
**2：**解决了包冲突的问题，在我们引入其他依赖时就不需要指定版本号了，父工程已经锁定了版本号，这些都是Spring帮我们打包好的
**3：**他运用了Maven的依赖具有传递性，如果要使用web相关内容，只需要使用一个Springboot-starter-web依赖，就可以使用web相关的内容，点进这个web依赖，就会发现它里面就依赖了很多相关web的坐标依赖，定义了所有可能用到的版本号，运用了Maven的依赖传递性

自动配置：
主要就是他的启动类
一个他的注解@Springbootapplication：
他是三个注解组成的,合成了一个注解@Springbootapplication
@Springbootapplication这个注解点进去可以看到他是一个自定义的注解类
这个自定义的注解类上面还有三个重要的注解
1:@SpringBootConfiguration：再进去也是注解类,他被@Configuration注解标识，声明为一个配置类,说明我们的启动类就是一个配置类
2:@ComponentScan：他就是spring IOC容器的扫描包，所以我们的Controler,service才能注入到容器中,他的扫描范围有两个,1:就是启动类所在包下的所有带注解的类,2:启动类所在包下所有子包带注解的类
3:@EnableAutoConfiguration：springboot实现自动化配置的核心注解。帮我配置我可能用到的所有的配置,他的依据就是:你的pom文件,你的pom文件引入了那些坐标,他就帮你配置哪些内容,点进去这个注解可以看到这个注解类上面导入了一个类,他这个类的主要作用就是根据pom文件引入的依赖,来判断哪些对象需要初始化,那些对象不需要初始化,那他判断需不需要的依据就是把他类里所有你可能用到的对象全部进行初始化,如果初始化失败,会报异常,那么就不会把这个对象放进容器.成功了就把成功的放入到容器中供我们使用
run方法：
1:我们通过进入这个方法可以看到这个方法的返回值是类型,
configurableApplicationContext他是个接口,然后再往下找
他继承了ApplicationContext，他也是一个接口
他继承了ListableBeanFactory，他也是一个接口
他继承了BeanFactory，BeanFactory<工厂对象>实际上就是SpringIOC容器，我们所有的bean都放在这个里面,所以说这个方法实际上就是创建了一个SpringIOC的容器
2:他这个方法有两个参数,第一个就是本类的字节码对象,将本类放入容器中
第二个参数args就是启动参数:就是项目启动时,传递给jvm初始化的一些参数栈堆的大小以及其他的jvm系统的参数
那他吧本类放入容器中,容器就会扫描这个类上的注解

**

SpringCloud相关==============================================

**

常用的五大组件:

Eureka:是一个注册中心 7001
他负责将服务提供者注册到Eureka的注册中兴,
Eureka：就是服务注册中心(可以是一个集群)，对外暴露自己的地址
服务提供者：启动后向Eureka注册自己的信息(地址，提供什么服务)
服务消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
他消费者可以是提供者,提供者也可以是消费者,它是将每个服务都注册到Eureka中心然后,服务获取

心跳(续约)：提供者定期向Eureka刷新自己的状态,默认90秒时效,心跳默认30秒发送一次
自我保护机制:

1. Eureka在运行期间会统计心跳失败的比例，在15分钟内是否低于85%,如果出现了低于的情况，Eureka Server会将当前的实例注册信息保护起来,，同时提示一个警告，表明进入了保护模式,就是说不会剔除任何服务,如果不是自我保护服务失效了,没有心跳续约,则会剔除,
2. 我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在eureka server配置文件中加上如下配置即可
3. 生产环境，不会频繁重启，所以，一定要把自我保护机制打开，否则网络一旦中断，就无法恢复。
4. Eureka在运行期间根据心跳失败比例决定是否进入保护模式。
5. 保护模式下，会保护服务注册表，不能删除，不会注销。
6. 开发阶段，我们最好关闭。生产环境选择打开。

Feign:
Feign是一个声明式WebService客户端,就是两个系统的远程调用,使两个系统进行数据交互.它的使用方法是5定义一个接口，然后在上面添加注解。不再需要拼接URL，参数等操作,只需要指定服务的名字就可以实现一个远程调用,服务与服务之间的调用,它的底层是使用resytemplet实现的,
它可以集成熔断器和负载均衡

Hystrix熔断器:
我们常用的是请求熔断和服务降级。
作用:解决雪崩效应
1.微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。 2.如果某服务出现异常，请求阻塞，用户得不到响应，容器中线程不会释放，于是越来越多用户请求堆积，越来越多线程阻塞。 3.单服务器支持线程和并发数有限，请求如果一直阻塞，会导致服务器资源耗尽，从而导致所有其他服务都不可用，从而形成雪崩效应；
Hystrix解决雪崩问题的手段，主要是
服务降级(兜底)，
2.服务降级(兜底方法)：优先保证核心服务，而非核心服务不可用或弱可用。触发Hystrix服务降级的情况：线程池已满、请求超时。
线程隔离；
1.线程隔离：是指Hystrix为每个依赖服务调用一个小的线程池，如果线程池用尽，调用立即被拒绝，默认不采用排队。
熔断器的状态有三种:
关闭:就是说关闭状态所有请求是正常的,当在一定时间内请求的失败比例达到设定的阈值,触发熔断,则会将熔断器彻底打开,默认设置失败比例是50%,请求次数最低不少于20次
全开:当时全开状态时,所有的请求都会被服务降级
半开:熔断器全开状态不是持续的,在全开一会后会进入休眠状态,默认是5秒,休眠过后会进入一个半开状态,这个时候呢,如果有请求他就会将这一个请求发过去,如果请求成功的话就回复关闭状态,如果失败,就再次全关,重复以上操作
服务降级的fallback方法
超时:
最小请求数等等

Ribbon负载均衡:
Ribbon默认提供的负载均衡算法：
轮询，
随机,
重试法,
加权

Gateway网关:
他取代了Zuul网关
网关作用：为微服务提供统一入口，然后对请求进行路由管理，可以在路由管理基础上进行一系列的过滤, 实现鉴权、动态路由等等操作。。
核心概念：通过画图解释
路由(route)：动态路由,也可以将路由地址写死,如果服务提供者集群的话，这样做不合理。应该是根据服务名称,动态获取

#路由的服务地址
#uri: http://localhost:18081静态
#lb协议表示从Eureka注册中心获取服务请求地址
#user-provider访问的服务名称。
#路由地址如果通过lb协议加服务名称时，会自动使用负载均衡访问对应服务
uri: lb://user-provider=====动态
路由配置中uri所用的协议为lb时，gateway将把user-provider解析为实际的主机和端口，并通过Ribbon进行负载均衡。
断言Predicate函数：符合它的配置才会被拦截,就是拦截规则
过滤器(Filter)：
系统自带过滤器:
加请求头/路径加参数/返回的响应加响应头/加前缀减前缀是以数字方式
自定义局部太麻烦不实用
自定义全局过滤器:
我们在项目中使用的过滤器是配置了判断用户请求是不是登录的地址,如果是就放行,去让用户登录,如果不是,则从请求路径/请求头/token中获取jwt令牌,如果获取到了,则吧令牌放入请求头中,然后放行,如果没有获取到则直接拒绝

Spring Cloud Config配置中心
他就是将各个微服务的配置文件上传到gitee仓库上,集中到一起,统一管理,通过配置中心,配置gitee的仓库地址,和对应的文件名,实现能远程使用配置文件,但是单单使用配置中心这样配的话,会存在问题,就是说在gitee上修改了配置文件后,如果项目不重启,就不生效,除非重启后才能生效,
所有就出了一个
Spring Cloud Bus消息总线他解决了配置中心不能实现配置自动更新的问题
需要加一个动态刷新的注解
他原理就是:???
文件命名有规则：
profile用于区分开发环境dev，测试环境test，生产环境pro等 开发环境 user-dev.yml 测试环境 user-test.yml 生产环境 user-pro.yml
流程???
搭建配置中心微服务
实现步骤：
1.
创建配置中心SpringBoot项目config_server
2.
配置坐标依赖
3.
启动类添加开启配置中心服务注解
4.
配置服务中心application.yml文件
5.
启动测试