服务雪崩问题
服务雪崩是指在微服务架构中，当某个服务出现故障或响应缓慢时，会导致依赖该服务的其他服务也出现故障，进而引发一系列连锁反应，最终导致整个系统崩溃的现象。
产生原因
- 高并发请求：大量请求同时访问某个服务，可能导致该服务过载，进而引发雪崩。
- 资源不足：服务器资源有限，无法处理过多请求，导致服务响应缓慢甚至崩溃。
解决方案
利用阿里巴巴开源的sentinel流控组件，实现服务限流、熔断、降级等多种服务保护功能。
1. 服务降级
降级是指当某个服务出现故障时，提供一个简化或者默认的响应，来代替正常的服务调用，保证核心业务不受影响。
feign使用sentinel是实现服务降级
feign接口实现降级
1.1. 引入sentinel依赖
<!--sentinel-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
1.2. 开启feign对sentinel的支持
feign:
sentinel:
enabled: true # 开启feign对sentinel的支持
1.3. 为FeignClient编写失败后的降级逻辑
@Slf4j
@Component
public class ItemClientFallbackFactory implements FallbackFactory<ItemClient> {
@Override
public ItemClient create(Throwable cause) {
return new ItemClient() {
@Override
public List<ItemDTO> queryItemByIds(Collection<Long> ids) {
log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);
cause.printStackTrace();
// 查询购物车允许失败，查询失败，返回空集合
return CollUtils.emptyList();
}
@Override
public void deductStock(List<OrderDetailDTO> items) {
log.error("远程调用ItemClient#deductStock扣减库存失败,参数:{}",items,cause);
}
};
}
}
1.4. feign接口配置fallbackFactory
@FeignClient(name="item-service",path = "/items",fallbackFactory = ItemClientFallbackFactory.class)
非feign接口实现服务降级
使用@SentinelResource注解实现。
@ApiOperation("查询购物车列表")
@SentinelResource(value = "queryMyCarts", fallback = "queryMyCartsFallback", blockHandler = "queryMyCartsBlockHandler")
@GetMapping
public List<CartVO> queryMyCarts(){
return cartService.queryMyCarts();
}
//当发生非限流非熔断异常走此方法
public List<CartVO> queryMyCartsFallback(Throwable throwable){
log.error("非限流、非熔断异常执行的降级方法，throwable:", throwable);
return new ArrayList<>();
}
//当发生熔断、限流走此方法
public List<CartVO> queryMyCartsBlockHandler( BlockException blockException){
log.error("触发限流、熔断时执行的降级方法，blockException:", blockException);
return new ArrayList<>();
}
2. 服务熔断
熔断是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。
熔断配置可直接通过sentinel面板进行配置，配置完即刻生效。
3. 服务限流
通过限制单位时间内访问服务的请求数量，防止服务过载。
限流配置可直接通过sentinel面板进行配置，配置完即刻生效。
分布式事务
分布式事务场景：
跨数据源完成一次事务：业务数据分布在多个数据库，一次事务操作需要跨多个数据库去完成，需要由多个服务远程调用协作去完成，远程调用依赖网络，由于网络问题会导致整体事务不能正常完成。 跨服务完成一次事务：用的一个数据库，但是跨服务通过远程调用去完成一次事务。
CAP理论
CAP理论的核心是：在分布式系统中，无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个需求，最多只能同时满足其中的两个。因此，分布式系统的设计者需要根据系统的实际需求和场景，权衡这三者之间的取舍。
- Consistency（一致性） ：所有节点在同一时间的数据是一致的。例如，当一个客户端对数据进行了更新操作，那么之后所有客户端对该数据的读取都会得到最新的值。
- Availability（可用性） ：每个请求都能得到响应，系统始终可用。即使部分节点出现故障，系统仍然能够对外提供服务。
- Partition tolerance（分区容错性） ：系统在遇到网络分区（即网络故障导致部分节点之间无法通信）的情况下，仍然能够继续运行。
CP：强调数据一致性。
AP：强调可用性，允许出现短暂不一致，最终达到数据一致性。
Seata
seata AT工作原理：
1、TM通知TC，开启全局事务。TC记录全局事务开启状态； 2、TM通知RM，开始执行分支事务。RM向TC注册分支事务； 3、RM执行自己的业务，并提交事务。同时在提交前后向unlog记录日志； 4、RM向TC汇报自己的事务执行成功或失败的状态状态； 5、TM通知TC，提交或回滚全局事务。TC检查全局事务中每个分支事务的状态，由TM统一提交或回滚事务； 6、提交：每个RM删除unlog表数据；回滚：每个RM根据unlog中的数据，执行反向操作。最后删除unlog数据。
