eureka

1.概念

Spring Cloud 不是技术或者某一框架，而是一系列框架的有序集合，是微服务架构的一站式解
决方案。目前主流的组件有alibaba的nacos、sentinel、gateway、openfeign

2.服务治理

在传统的 RPC 远程调用框架中，服务与服务之间的依赖关系非常复杂，通过服务治理实现：服
务调用、负载均衡、容错、服务的注册与发现等

3.Eureka

1.两个组件：client和server,通过心跳机制保持连接,将地址注册到服务中心，通过拉取地址来
进行远程调用
2.心跳机制：在应用启动后，Eureka Client 将会向 Eureka Server 发送心跳连接（周期为
30s）。如果Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将 
会从服务注册表中把这个服务节点移除（默认 90s）
3.自我保护：保护模式，主要用于一组客户端 和 Eureka Server 之间存在网络分区场景下的保
护。一旦进入保护模式，Eureka Server 将会尝试保护其服务注册表中的信息，不再删除服务注
册表中的数据，也就是不会注销任何微服务实例。当我们在 Eureka Server 服务首页中，看到有
如下这段提示，则说明此时 Eureka Server 已经进入了保护模式。 Eureka 的自我保护机制，就
是CAP 原则中的 AP 分支。即满足：可用性、分区容错性。

4.关闭自我保护（延迟、卡顿、拥挤）：

eureka:
  server:
    #关闭自我保护机制，保证不可用服务被及时剔除
    enable-self-preservation: false
    #清理无效节点的时间间隔,默认60000毫秒,即60秒 (此处时间间隔设置为2s)
    eviction-interval-timer-in-ms: 2000
eureka:
  instance:
    # Eureka客户端向服务端发送心跳的时间间隔,单位为妙(默认是30s)
    lease-renewal-interval-in-seconds: 1
    # Eureka服务端在收到最后一次心跳后的等待时间上限,单位为秒(默认90s),超时将移除服务
    lease-expiration-duration-in-seconds: 2

==================================分割线===================== ribbon

1.概念

它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个 Spring 
Cloud 构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上
都是通过 Ribbon 来实现的，包括后续我们将要介绍的 Feign，它也是基于 Ribbon实现的工
具。所以，对 Spring Cloud Ribbon 的理解和使用，对于我们使用 Spring Cloud来构建微服务
非常重要。

2.负载均衡

a.nginx独立的负载均衡设;b.ribbon负载均衡逻辑集成到消费方
b.轮询、重试、随机
c.这个自定义算法配置类，是不能够放在 @ComponentScan 所扫描的当前包下以及子包下。 否
则我们自定义的负载均衡算法将会被所有的 Ribbon 客户端所公用，达不到特殊化定制的目的。
import com.study.loadbalance.MyRule;
@SpringBootApplication
@EnableEurekaClient
//将轮询方式，修改为随机方式(name为服务名,指定那个服务用哪种负载均衡策略)
@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration = MyRule.class)
public class OrderMain80 {
    public static void main(String[] args) {
        SpringApplication.run(OrderMain80.class, args);
    }
}
d.eureka和openfeign目前都是集成了ribbon

==================================分割线===================== openfeign

1.概念

声明式rest客户端@EnableFeignClients @FeignClient(value = "CLOUD-PAYMENT-SERVICE")

2.OpenFeign 超时控制

服务消费者在进行服务调用时，由于网络、查询效率 等问题，导致消费者不能及时获取返回数
据，这就是 Feign 的超时控制。默认 Feign 客户端只等待 1 秒钟，但是服务端处理需要超过1
秒钟，从而导致 Feign 客户端不再继续等待，直接以超时报错的方式返回。为了避免这类情
况，我们就需要设置 Feign 客户端的超时控制。application.yml 中配置 ribbon.ReadTimeout 
和 ribbon.ConnectTimeout 两个属性，并设置允许的超时时间即可,或者对应的兜底方案

==================================分割线===================== Hystrix服务降级、服务熔断、服务限流转自blog.csdn.net/lzb34811017…

1.服务降级

服务端实现服务降级：@EnableCircuitBreaker  //激活Hystrix断路器
消费端实现服务降级：

2.服务熔断

服务降级和服务熔断的区别：
  服务降级 → 当前服务还是可用的；（比如有10个线程，谁抢到谁用，抢不到如果超时报提错
  误提示，下一次抢到还能继续提供服务）
  服务熔断 → 当前服务不可用，但是它会逐渐恢复服务提供；(拉闸，整个家用电器都不能用；
  然后测试开5个电器没问题，6个也没问题，逐渐的就恢复服务提供)

==================================分割线=====================

1.MQ的概念

消息队列（Message Queue），是一种跨进程的通信机制，用于上下游传递消息。
实现了生产者和消费者的解耦。消息的生产和消费都是异步的
使用场景一：数据统计任务，这些任务之间有一定的依赖关系

典型场景二：上游不关心执行结果
课程服务要增加课程评论数量，积分服务要奖励用户积分，消息服务要给管理员发送站内消息。

2.工作原理

3.组成

Message：
消息，由消息头和消息体组成。而消息头则由一系列的可选属性组成，包括routing-key（路由键）、priority（相对于
其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。 
Binding：
绑定，用于消息队列和交换机之间的关联。一个绑定就是基于路由键将交换机和消息队列连接起来的路由规则。

4.消息模型

a.基本消息模型（simple简单消息）：

消费者已经获取了消息，但是程序没有停止，一直在监听队列中是否有新的消息。一旦有新的消息进入队列，就会立即打印。
如果消息不太重要，丢失也没有影响，那么自动ACK会比较方便。
如果消息非常重要，不容丢失。那么最好在消费完成后再手动ACK。

b.工作队列或者竞争消费者模式(work)。

  多个消费者存在时可以指定任务分配的策略
    面试题：如何避免消息堆积？
  1）采用work queues，多个消费者监听同一队列。
  2）接收到消息以后，通过线程池，异步消费。

c.发布/订阅

c.1.exchange类型

Fanout：广播，将消息交给所有绑定到交换机的队列

Direct：定向，把消息交给符合指定routing key 的队列

Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列
`#`：匹配一个或多个词
`*`：匹配不多不少恰好1个词

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合
路由规则的队列，那么消息会丢失！

d.持久化

面试题：如何避免消息丢失？
1） 消费者的ACK机制。可以防止消费者丢失消息。
2） 但是，如果在消费者消费之前，MQ就宕机了，消息就没了。
面试题：是否可以将消息进行持久化呢？
要将消息持久化，前提是：队列、Exchange都持久化

e.重复消费

a.由于生产者发送消息给MQ，在MQ确认的时候出现了网络波动，生产者没有收到确认，实际上MQ已经接收到了消息。这时
候生产者就会重新发送一遍这条消息。生产者中如果消息未被确认，或确认失败，我们可以使用定时任务+（redis/db）
来进行消息重试。
b.消费者消费成功后，再给MQ确认的时候出现了网络波动，MQ没有接收到确认，为了保证消息被消费，MQ就会继续给消费
者投递之前的消息。这时候消费者就接收到了两条一样的消息。
c.让每个消息携带一个全局的唯一ID，即可保证消息的幂等性，具体消费过程为
转自：https://www.cnblogs.com/zhixie/p/13444213.html

==================================分布式事务=====================

1.概念

a.一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，每个服务内部的数据一致性由本地事务来保证，但是
全局的数据一致性问题没法保证
b.seata主要的四个概念：
	全局唯一事务id和如下图的三组件
    tc:维护全局事务和分支事务的状态（汇总事务信息，决定分布式事务是提交还是回滚）
    tm:向tc注册分支事务，（通知tc是否要提交/回滚）并进行事务的提交和回滚
    rm:向tc注册全局事务，并进行事务的提交和回滚

c.分布式事务执行流程

==================================分布式锁==================== ==================================分布式id=====================

springcloud

1.概念

2.服务治理

3.Eureka

4.关闭自我保护（延迟、卡顿、拥挤）：

1.概念

2.负载均衡

1.概念

2.OpenFeign 超时控制

1.服务降级

2.服务熔断

1.MQ的概念

2.工作原理

3.组成

4.消息模型

a.基本消息模型（simple简单消息）：

b.工作队列或者竞争消费者模式(work)。

c.发布/订阅

c.1.exchange类型

d.持久化

e.重复消费

1.概念