微服务重要知识点
Spring Cloud
五个组件
通常情况下：
Eureka：注册中心
Ribbon：负载均衡
Feign：远程调用
Hystrix：服务熔断
Zuul/Gateway：网关
阿里巴巴组件：
Nacos：注册中心/配置中心
Ribbon：负载均衡
Feign：服务调用
Sentinel：服务保护
Gateway：服务网关
服务注册
注册中心的核心作用：服务注册和发现。
常见的注册中心：Eureka、Nacos、Zookeeper。
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等。
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用。
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除。
如果设置为非临时实例，注册中心会主动询问服务提供者。
如果服务提供者服务信息变更，注册中心会主动推送变更消息。
Nacos和Eureka的异同？
共同点：
1. 都支持服务注册和服务拉取。
2. 都支持服务提供者心跳模式做健康检测。
不同点：
1. Nacos支持服务端主动检测提供者状态；临时实例采用心跳模式，非临时实例采用主动检测模式。
2. 临时实例心跳不正常会被剔除，非临时实例不会被剔除。
3. Nacos支持服务列表变更的消息推送模式，服务列表更新更及时。
4. Nacos集群默认采用AP模式（高可用模式），当集群中存在非临时实例时，采用CP模式（强一致模式）；Eureka采用AP模式。
5. Nacos还支持了配置中心，Eureka只有注册中心。
负载均衡
Ribbon负载均衡流程
Ribbon负载均衡策略
1. RoundRobinRule：简单轮询服务列表来选择服务器。
2. WeightedResponseTimeRule：按照权重来选择服务器，相应时间越长，权重越小。
3. RandomRule：随机选择一个可用的服务器。
4. BestAvailableRule：忽略那些短路的服务器，选择并发数较低的服务器。
5. RetryRule：重试机制的选择逻辑。
6. AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例。
7. ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
熔断、降级
什么是服务雪崩，怎么解决这个问题？
定义：一个服务失败，导致整条链路的服务都失败的情形。
服务降级
服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求徒增影响变得不可用，确保服务不会崩溃。
服务熔断
Hystrix熔断机制，用于监控微服务调用情况，默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker。
如果检测到10秒内请求的失败率超过50%，就会触发熔断机制。之后每隔5s重新尝试请求微服务，如果微服务不能相应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。
监控
为什么要监控？
问题定位、性能分析、服务关系、服务告警。
Springboot-admin、prometheus+Grafana、zipkin、skywalking。
Skywalking
一个分布式系统的应用程序性能监控工具（Application Performance Management），提供了完善的链路追踪能力，apache的顶级项目。
服务（service）：业务资源应用系统（微服务）
端点（endpoint）：应用系统对外暴露的功能接口（接口）
实例（instance）：物理机
业务相关
限流
为什么要限流？
1. 并发量太大（突发流量）。
2. 防止用户恶意刷接口。
如何限流？
Tomcat：可以设置最大连接数。
Nginx：漏桶算法。
网关：令牌桶算法。
分布式事务
CAP定理
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
Availablity（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
Partition tolerance（分区容错性）：
Partition分区：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。
Tolerance容错：在集群出现分区时，整个系统也要持续对外提供服务。
分布式系统无法同时满足这三个指标。
分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的。
如果保证访问的高可用性（A），可以持续对外提供服务，但不能保证数据的强一致性 --> AP。
如果保证访问的数据强一致性（C），就要放弃高可用性 --> CP。
BASE理论
Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
解决分布式事务的思想和模型
1.最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）。
2.强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚（CP）。
分布式事务解决方案
Seata架构
Seata事务管理中有三个重要的角色：
TC（Transaction Coordinator）事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM（Transaction Manager）事务管理器：定义全局事务的范围，开始全局事务、提交或回滚全局事务。
RM（Resource Manager）资源管理器：管理分支事务处理的资源，与TC事务协调者交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
XA模式（CP模式，强一致性）
RM一阶段的工作：
1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC
TC二阶段的工作：
TC检测各分支事务执行状态
a.如果都成功，通知所有RM提交事务
b.如果有失败，通知所有RM回滚事务
RM二阶段的工作：
接收TC指令，提交或回滚事务
AT模式（AP模式，最终一致性）
阶段一RM的工作：
注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态
阶段二提交时RM的工作：
删除undo-log即可
阶段二回滚时RM的工作：
根据undo-log恢复数据到更新前
TCC模式（AP模式，最终一致性）
1. Try：资源的检测和预留。
2. Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
3. Cancel：预留资源释放，可以理解为try的反向操作。
分布式服务接口幂等
幂等性
多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单词调用的结果一致。
场景
用户重复点击/网络波动、MQ消息重复、应用使用失败或超时重试机制。
请求方式 | 说明 |
GET | 查询操作，天然幂等 |
POST | 新增操作，请求一次与请求多次造成的结果不同，不是幂等的 |
PUT | 更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的 |
DELETE | 删除操作，根据唯一值删除，是幂等的 |
方案
数据库唯一索引（解决新增）
token+redis（解决新增、修改）
分布式锁（解决新增、修改）
Redisson分布式锁
尝试获取锁，获取成功则处理业务，获取失败则快速失败。
分布式任务调度
xxl-job
解决集群任务的重复执行问题。
cron表达式定义灵活。
定时任务失败，重试和统计。
任务量大，分片执行。
xxl-job路由策略？
1. FIRST（第一个）：固定选择第一个机器。
2. LAST（最后一个）：固定选择最后一个机器。
3. ROUND（轮询）：按照顺序选择机器。
4. RANDOM（随机）：随机选择在线的机器。
5. CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
6. LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举。
7. LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举。
8. FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度。
9. BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度。
10. SHARDING_BROADCAST（分片广播）：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务。
xxl-job任务执行失败怎么解决？
故障转移+失败重试，查看日志分析----> 邮件告警。
如果有大数据量的任务同时都需要执行，怎么解决？
执行器集群部署时，任务路由策略选择分片广播情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务。
