分布式
CAP原则
CAP原则也称为CAP原理，是指在一个分布式系统中，包含3个基本需求：
- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance） 这3个基本需求，最多只能同时满足其中的2个。
BASE理论
BASE理论是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性，也可以根据应用特点采用适当的方式来达到最终一致性的效果。
BASE的主要含义：
- Basically Available（基本可用）
- Soft State（软状态）
- Eventually Consistent（最终一致性）
分布式锁有哪些实现方式？
- Mysql分布式锁，基于数据库对字段作唯一约束。
- Redis分布式锁，基于Redis的单线程及lua脚本的原子操作。
- Zookeeper分布式锁，创建顺序临时节点。
分布式事务有哪些常见的实现方案？
- 2PC：二阶段提交
- 3PC：三阶段提交
- TCC：Try Confirm Cancel
- 本地消息表
- MQ消息事务
- 最大努力通知
- SAGA事务
分布式一致性算法：Paxos算法
定义
Paxos 算法是 基于消息传递 且具有 高效容错特性 的一致性算法，目前公认的解决 分布式一致性问题 最有效的算法之一。
角色
Paxos 算法包含三个角色：
- Propose（提议者）：提议者提起议案，用于投票表决。
- Acceptor（接受者）：对议案投票，并接受达成共识的投票。
- Learner（学习者）：被告知投票结果，接受达成共识的投票。
缺陷
当有多个提议者互不想让时，会导致系统陷入死循环。Multi Paxos是对这个问题的改进，核心思想是选举出一个leader（领导者），由leader提起议案。
分布式一致性算法：Raft算法
定义
Raft 也是一个 一致性算法，和 Paxos 目标相同。但它还有另一个名字 - 易于理解的一致性算法。Paxos 和 Raft 都是为了实现 一致性 产生的。这个过程如同选举一样，参选者 需要说服 大多数选民 (Server) 投票给他，一旦选定后就跟随其操作。Paxos 和 Raft 的区别在于选举的 具体过程 不同。
角色
Raft 协议将 Server 进程分为三种角色：
- Leader（领导者）
- Follower（跟随者）
- Candidate（候选人）
幂等性
定义
同一个接口，接受多次请求，请求的结果是一致的。简单说，就是多次调用如一次。
PS：幂等性与防重不一样，防重是防止数据重复，幂等性是多次调用如一次，防重包含幂等。
怎么保证接口幂等性？
- insert前先select
- 加唯一索引
- 加悲观锁：锁定数据
- 加乐观锁：不锁数据，加version子弹控制。
- 建防重表：存储消息的唯一id。
- 状态机：有些业务是有状态的，比如支付状态，1-未支付 2-支付中 3-支付成功 4-支付失败
- 分布式锁
- token机制
分布式限流算法
计数器
定义一个计数器，指定时间和最大请求数量，表示在一段时间内只能接受指定数量的请求，每接受一个请求则递增计数器，超过数量后则拒绝新增请求，超过指定时间后重置计数器。
漏桶算法
漏桶内存放请求，请求从上进入漏桶，请求从漏桶底部已恒定速度流出并被处理。漏桶的容量有限，超过容量的请求会被丢弃。系统处理请求的速度恒定。
漏桶算法可以以恒定速度处理请求，系统比较稳定。但如请求数量突然增加，因为系统处理请求速度，无法快速处理突增的请求，会造成大量请求被丢弃。
令牌桶算法
漏桶内存放令牌，已恒定速度向漏桶存放令牌，超过漏桶容量则不再放入令牌。有请求进入时，则从漏桶内获取令牌。如能获得令牌则处理请求。如无法获取令牌，则丢弃请求。
令牌通算法同时达到了限流和快速处理突增请求的需要。