注册中心
Nacos和Eureka
- 共同点
- 都可以作为服务注册，服务拉取中心。
- 都有AP特性。
- 都支持服务提供者心跳方式做健康监测。
- 异同点
- nacos可以做配置中心。
- nacos可以支持服务提供者注册服务为非临时实例时:
- nacos为CP模式。
- nacos会主动监测服务提供者是否存活。
- nacos会主动通知服务列表的更新（更快感知服务变更）。
- 服务提供者心跳不正常AP模式会被剔除服务列表，CP模式则不会。
- 当nacos可以支持服务提供者注册服务为临时实例时，和Eureka一样。
负载均衡
Ribbon
负载均衡
-
轮询方式
-
随机方式
-
响应时间加权轮询方式
-
分区轮询方式
-
自定义轮询：
-
声明创建SpringBean(全局配置)
@Bean public IRule customRule(){ // implements IRule return new new CustomeRule(); }
-
-
在配置文件中指定服务使用自定义轮询全限定类名（局部配置）
熔断机制
hyrtix
根据10S内请求失败率是否过半来判断要不要打开熔断机制，走fallback接口服务降级机制，随后半开状态会每隔5S判断服务是否可达可用标准，如果达到则关闭熔断机制，否则继续保持服务降级。
服务限流
nginx
- 漏桶算法
以固定桶的大小来充当容器，其他的请求抛弃，同时在桶下面开启固定大小的出口来限定速率。
- 控制并发连接数
- perip
- perserver
网关
-
令牌桶算法
固定速率放入令牌桶，请求到来后看桶中的令牌数决定每秒并发，和漏桶的区别就在于令牌桶的瞬时速率可能会double（eg:一直没有请求进来，令牌桶中已经有了三个令牌，同时桶外已经有三个令牌等待入桶，此时桶中三个令牌颁发出去之后，桶会立马被补满又可以颁发三个，瞬时速率就可以double变为6）
-
自定义拦截器
guava 或者 redis （ Sorted Set ）
AP&CP
CAP：分布式系统的三要素：一致性、可用性、分区容错性。
因为现在的集群大多都要保证一半以上的节点存活，所以分区容错性是保障。P
CP：当系统想要满足一致性时，节点之前的同步力度就要大很多，甚至到了一定要同步的地步，就会出现部分节点可用，部分节点不可用（对于客户端来说这部分节点都是脏数据、落后数据、甚至拒绝连接）的情景，就满足不了可用性。
AP：当系统想要满足可用性时，就要舍弃强一致性，允许部分节点同步滞后，网络宕机。
BASE则是以牺牲强一致性为代价，追求系统的可用性和分区容错性，通过保证基本可用性、软状态和最终一致性来解决CAP问题。
具体来说，BASE包含以下三个概念：
- 基本可用性（Basically Available）：系统在面对异常情况时，仍然可以保证核心功能的正常运行。即使某些服务出现故障或延迟，仍然能够接收并处理部分请求。
- 软状态（Soft State）：允许系统在不同节点上存在数据副本的不一致状态，即系统中的数据可能存在短暂的不一致。
- 最终一致性（Eventual Consistency）：系统经过一段时间的同步与协调后，最终会达到一致的状态。即系统中的数据副本最终会在合理的时间范围内达到一致。
举例来说，一个使用BASE理论的分布式系统可以采用异步复制方式处理数据一致性问题。当用户提交数据时，系统首先对数据写入本地节点，并立即返回成功响应，保证了基本可用性。然后，系统异步地将数据复制到其他节点，以实现最终一致性。
分布式事务
MQ
使用MQ解耦各个步骤里的业务分支事务，通过MQ来通信。
SETA
通过事务协调器来协调各分支事务的提交和回滚。
接口幂等性
新增和更新实现幂等：
-
update 绝对值 而非操作符
update t1 set cost= 500 where id=1; ✔ update t2 set cost = cost - 500 where id=1; -
新增
- 使用唯一索引新增
- Token&Redis （性能最好）
- 分布式锁