一、理论
1. CAP定理
一个分布式系统中， 一致性， 可用性，和分区容错性这个三个基本要素，只能满足其中两个 https://juejin.im/post/5b26634b6fb9a00e765e75d1
2. BASE理论
BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。
3. 一致性算法/协议
3.1. 2PC协议
角色：参与者， 协调者
- 准备阶段(投票)：事务询问->本地事务执行->事务响应,阻塞等待
- 提交阶段（执行）： 针对第一阶段的提交情况，若全部能正常执行事务，则发起事务提交通知； 若一个或者多个返回失败，或者超时，则发起事务回滚通知；
- 不同角色的状态转换
- 有同步阻塞(等待协调者调度)、单点问题（协调者）、数据不一致（第二阶段发出提交事务的通知， 结果。。没被部分参与者收到）
3.2. 3PC协议
角色: 参与者、协调者
- CanCommit: 1. 协调者询问参与者，是否正常， 参与者给个预估值。
- PreCommit: 1. 若协调者得到确定信息，则发送事务执行通知， 参与者执行事务不提交并返回执行状态；2. 若协调者得到否定消息，或者超时，则发出abort通知。
- DoCommit: 和2PC协议的提交阶段一致, 只是若参与者没有收到commit/rollback通知， 则在超时后执行commit
- 不同角色的状态转换
- 相对于二阶段提交，三阶段提交主要解决的单点故障问题，并减少了阻塞的时间。但没解决一致性问题， 网络延时带来的超时， 导致abort响应不及时，执行了commit….
3.3. TCC
Try confirm cancel
3.4. Paxos
- 解决分布式一致性最有效的算法之一。
- 角色：Proposer, acceptor, Learner；名词：提议（value）, 编号（唯一、自增id）
- 投票的过程
- prepare阶段：proposer 如果从多数acceptor中得到一个被接受的提议，那么即使id最大(更新最小编号，后续accept阶段，不接受小于这个的提议)，也要接受提议。否则可以提自己的提议。
- accept阶段：acceptors 更新接受的提议和编号
- learn阶段：发送给所有的learner
- 伪代码实现
3.5. Raft
- 易于理解的一致性算法。正常工作时只有一个leader, 多个followers, 当leader挂了，则重新选举。
-
角色：Leader(同步、和提交告知), follower(遵循leader的告知信息), candidate(选举过程的临时角色)
- 选举过程–穷举了最小集群（三个节点）
二、分布式锁
在分布式环境下，如何保证不同节点的同步执行某段代码？
- memcached的add操作
- Redis setnx操作（有坑）, Set + 守护进程(续命), 细说redis分布式锁
- zk的顺序临时节点
- Chubby, 粗粒度分布式锁服务， 底层paxos实现
三、扩展性设计
1. 数据切分
- 水平拆分：基于某个字段，比如对uin取模
- 垂直拆分：不同的功能，分库
2. 扩展性
- 应用间较少依赖和耦合，对修改关闭，对扩展开放
- 业务模块的分解、服务组件的拆分
- 拆分后通过消息队列、分布式服务(rpc等)来聚合
3. 伸缩性
通过增加资源，来增加业务的处理能力。比如扩容、加机器
四、稳定、高可用
参照微服务的容错
1. 应用层容灾
1.1. Hystrix 熔断器
1.2. 缓存
- 穿透：高频访问某个不存在的Key
- 击穿：热点key在过期时间点，被大量访问
- 雪崩：key设置相同的过期时间
2. 跨机房容灾（异地多活）
- 延时
- 专线
- 数据维度、用户路由一致性
- 数据正确性、同步
