分布式

CAP

分区容错性 是指分布式网络中部分网络不可用，但系统依然正常对外提供服务。

比如：北京的订单系统，访问上海的库存系统，可能导致失败。如果发生失败，就要在A和C之间做出选择。 要么停止系统进行错误恢复，要么继续服务但是降低一致性，所以说只能保证AP或CP。

所以，只要是分布式系统，因为网络故障是百分百存在的，所以P是必备的，剩下的就是AP还是CP了

如何保证幂等

所谓幂等，其实就是说你这个操作，执行1次和多次返回的结果是一样的。

1. 用数据库唯一键实现
2. 业务实现，执行前先查询是否存在或者状态字段来判断是否已经处理过了
3. 颁发token，再加分布式锁，处理完之后删除token，下一个同样的请求就被拦截住了

分布式锁

什么是分布式锁？

在分布式环境下，多个线程需要操作同一份资源，只允许一个线程进行操作。

数据库实现

可以基于数据库，新增一条数据，uk唯一键来实现，或者根据for update来实现，都可以。

前提肯定是需要根据业务有一个唯一的key，也就是锁，然后新增成功就说明获取锁成功，业务执行完成之后就删掉即可。

redis实现

setnx()来实现， setnx(lockkey, 当前时间+过期超时时间)，如果返回 1，则获取锁成功；如果返回 0 则没有获取到锁。

服务降级和熔断

注意，实际场景中熔断和降级貌似是一体的，触发接口的异常阈值，则走callback方法，如果想单独走降级的话，则可以采用配置中心的方法来实现。

如果熔断器没有配置callback,则会直接抛出HystrixTimeoutException异常

• 服务熔断：主动切断故障服务的调用，防止雪崩，保护调用方。是一种故障检测和恢复机制。
• 服务降级：主动关闭非核心服务，释放资源，保障核心业务。是一种资源调配和保稳策略。 举例说明：

场景：一个电商网站，其下单功能依赖于“库存服务”和“推荐服务”。

1. 服务熔断的例子：

   • 库存服务突然响应极慢或大量超时。
   • 熔断器会快速检测到这种故障，立即“跳闸”。
   • 后续所有对库存服务的调用都会被直接拒绝或返回一个预设的降级值（如“库存检查中”），而不再真正发起请求。
   • 目的：防止大量请求线程被挂起，导致订单服务本身也因资源耗尽而崩溃。

2. 服务降级的例子：

   • 在“双十一”大促期间，系统流量激增，为了保证核心的下单、支付流程能正常运行。
   • 系统主动关闭了“推荐服务”（比如“猜你喜欢”）这类非核心但耗资源的功能，显示一个简单的静态页面。
   • 目的：将节省下来的CPU、内存、数据库连接等资源，全部让给核心交易链路，保证整体系统不宕机。

总结：熔断是 “因为它坏了，所以我不用它” ；降级是 “虽然它没坏，但为了大局，我先不用它” 。

限流

redis实现

利用redis的计数器，原理是，给这个秒杀接口url （作为key）初始化值1，如果是第一次的话，就给这个key设置过期时间60s， 我们限制秒杀接口一分钟最多1w个请求。没来一次请求就加一，超过1w就返回 人数较多，请稍后再试。还可以限制ip，用户，等等条件。无非是key改变下就可以了

滑动窗口限流

可以自己用java实现，也很简单

第三方组件

alibaba-sentinel 限流组件。非常简单好用而且强大

秒杀场景

• 前端：页面静态化，cdn，验证码，防抖。
• 后端：限流，redis+lua脚本实现高性能秒杀