JAVA分布式架构完整知识体系
原创2021-03-14 11:18·后端研发Marion## 本文目录结构（推荐学习时间8小时）
一、分布式理论基础
1. CAP理论
2. BASE理论
3. 数据一致性理论(副本、协调者、分布式协议2PC 3PC、选举、逻辑时钟)
4. 数据一致性模型
二、分布式缓存
1. 缓存的更新模式
2. 缓存的失效机制
3. 缓存的淘汰策略
4. 缓存穿透、缓存击穿、缓存雪崩
5. 缓存设计时几个需要关注的点
6. 缓存中的热key和大value问题
三、分布式锁
1. 为什么要使用分布式锁？
2. 分布式锁需要具备的条件
3. 分布式锁的三种实现方式
4. 三种方式对比
四、分布式事务
1. 两阶段提交（2PC）
2. 三阶段提交（3PC）
3. 补偿事务（TCC）
4. 本地消息表（异步确保）
5. 消息事务
6. 最大努力通知
7. 总结
五、分布式Session
六、从零开始写分布式服务框架
1. 第1章 常用的RPC框架 1
2. 第2章 分布式服务框架总体架构与功能 69
3. 第3章 分布式服务框架序列化与反序列化实现 75
4. 第4章 实现分布式服务框架服务的发布与引入 119
5. 第5章 分布式服务框架注册中心 159
6. 第6章 分布式服务框架底层通信实现 190
7. 第7章 分布式服务框架软负载实现 348
8. 第8章 分布式服务框架服务治理 362
## 分布式理论基础
### 一、CAP理论
CAP理论是指在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
1. `C (Consistency)，一致性`：数据在分布式系统中的多个副本之间保持一致的特性。在数据一致的某个时间点，执行更新操作后，也要求系统各部分数据是一致的。
2. `A (Availability)，可用性`：服务随时可用，即使某些节点发生故障也不影响集群的对外服务。
3. `P (Partition)，分区容错性`：分区容错性约束了分布式系统在遭遇任何网络分区后（部分网络分区故障），仍要对外提供一致性和可用性的服务。（注：网络分区，即在分布式系统内，不同节点归属在不同网络子网，子网络之间可能出现网络不连通情况，但在子网内部的通信是正常的。）
### 二、BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP理论中一致性（A）和可用性（C）权衡的结果，来源于对大规模互联网系统分布式实践的结论。
1. BA (Basically Available) ，基本可用：分布式系统出现故障时，允许损失部分可用性，保证核心可用。
2. S (Soft state) ，软状态：系统中的节点数据允许存在中间状态，该中间状态的存在不会影响到整体的可用性，这通常体现在数据在一致性同步复制过程中，允许存在延时。
3. E (Eventually consistent)，最终一致性：系统中所有数据副本经过一段时间同步后，最终能够达到一致的状态。
### 三、数据一致性理论(副本、协调者、分布式协议2PC 3PC、选举、逻辑时钟)
#### 1. 数据一致性问题
1. `消息传递异步无序`: 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序。
2. `节点宕机`: 节点持续宕机，不会恢复。
3. `节点宕机恢复`: 节点宕机一段时间后恢复，在分布式系统中最常见。
4. `网络分化`: 网络链路出现问题，将N个节点隔离成多个部分。
5. `拜占庭将军问题`：节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息。
#### 2. 副本
1. 当前一般通过复制技术进行分布式系统的一致性的保证
2. 不同的数据节点由于网络延迟、操作链中一环失败等原因，往往造成数据不一致的问题。
#### 2. 协调者
* 分布式事务中通知和协调数据库提交或回滚的角色
#### 3. 分布式协议（2PC、3PC）
常见的分布式协议有：2PC（两阶段提交）、3PC（三阶段提交）,他们也不能根除数据不一致性问题。
1. 2PC（两阶段提交）：我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)。
1. `准备阶段(投票阶段)，PreCommit`。协调者发起一个提议，分别问询各参与者是否接受。
2. `提交阶段（执行阶段），doCommit`。协调者根据参与者的反馈，提交或中止事务，如果参与者全部同意则提交，只要有一个参与者不同意就中止。
2. 3PC（三阶段提交）
3PC是2PC的改进版本，引入了超时机制，加入一个新的CanCommit阶段。
1. CanCommit阶段：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1. `事务询问`：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2. `响应反馈`：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
2. PreCommit阶段：协调者根据参与者CanCommit阶段的反应情况来决定是否可以记性事务的PreCommit操作。若获得no响应，则中断 1. `事务`；若获得yes响应，则，
发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2. `事务预提交`：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3. `响应反馈`：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
3. DoCommit阶段：该阶段进行真正的事务提交，若没有收到ACK响应则中断事务、回滚；若收到ACK响应，则，
1. `发送提交请求`：协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2. `事务提交`：参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3. `响应反馈`：事务提交完之后，向协调者发送Ack响应。
4. `完成事务`：协调者接收到所有参与者的ack响应之后，完成事务。
4. 选举、多数派、租约
1. 选举
1. `Bully算法`：每个节点对应一个序号，序号最高的节点为leader。leader宕机后次高序号的节点被重选为leader。2. 缺点：网络分化情况下，将产生多个leader
2. 多数派</p>
1. `原理`：多数派的原理说起来很简单，假如节点总数为2f+1，则一项决议得到多于 f 节点赞成则获得通过。
2. `优点`：避免多个leader
3. 租约
1. `原理`：中心思想是每次租约时长内只有一个节点获得租约、到期后必须重新颁发租约
2. `优点`：租约机制确保了一个时刻最多只有一个leader，避免只使用心跳机制产生双主的问题，`如Zookpeer`
5. 逻辑时钟-参考 `参考附录1`
### 四、数据一致性模型 `参考附录1`
1、强一致性
2、弱一致性
3、最终一致性
4、最终一致性模型的变种
## 分布式缓存
### 一、缓存的更新模式 `参考附录2`
1. Cache Aside 模式（重点，主流）
1. 原理：缓存更新时先更新数据库，然后在让缓存失效
2. 流程
1. `命中`：应用程序从 cache 中取数据，取到后返回。
2. `失效`：应用程序先从 cache 取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
3. `更新`：先把数据存到数据库中，成功后，再让缓存失效。
3. 常见问题：
1. `先更新数据库，再更新缓存`：两个并发的写操作导致脏数据
1. 在Read/Write Through 模式中，缓存代理了DB读取、写入的逻辑，可以把缓存看成唯一的存储。先更新缓存，缓存负责同步更新数据库。
2. Read Through： 模式就是在查询操作中更新缓存，也就是说，当缓存失效的时候，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载。
3. Write Through 模式和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后由缓存自己更新数据库（这是一个同步操作）。
3. Write Behind Caching模式
* 这种模式下所有的操作都走缓存，缓存里的数据再通过异步的方式同步到数据库里面。所以系统的写性能能够大大提升。
4. 三种模式总结
1. Cache Aside 更新模式简单
2. Read/Write Through 更新模式只需要维护缓存
3. Write Behind Caching 更新模式异步，处理并发高，但牺牲了强一致性
4. 缓存一定要合理的设置过期时间
### 二、缓存的失效机制 `参考附录2`
1. 主动失效
2. 被动失效
### 三、缓存的淘汰策略 `参考附录2`
1. LRU
2. LFU
3. FIFO
### 四、缓存穿透、缓存击穿、缓存雪崩 `参考附录2`
1. 缓存穿透
2. 缓存击穿
3. 缓存雪崩
### 五、缓存设计时几个需要关注的点 `参考附录2`
1. 不要把所有的数据都加载到缓存中。
2. 缓存需要有一个失效机制。
3. 缓存的代价是牺牲了数据的强一致性。
### 六、缓存中的热key和大value问题 `参考附录2`
1. 在分布式缓存中，面对高并发要求有两个问题非常重要：热key问题（hot key）和大value（big value）问题。
1. 热key问题：是指缓存集群中的某个key在瞬间被数万甚至十万的并发请求打爆。
2. 大value问题：是指某个key对应的value可能有gb级别的大小，导致查询value的时候会引发网络相关的故障问题。
2. 热key问题定义
1. 热key问题是指：突然有几十万甚至更大的请求去访问redis上的某个特定key。这样会造成流量过于集中，达到Redis单实例瓶颈（一般是10W QPS级别），或者物理网卡上限，从而导致这台redis的服务器Hold不住，直到缓存服务器垮掉。
2. 发现热key
1. 按业务场景，预估热点key（常用）
2. 客户端收集（常用）
3. 代理层收集
4. redis监控命令（常用）
5. 网络抓包分析
6. 基于大数据流式计算技术的缓存热点自动发现
3. 解决方案
4. 总结
1. 每台redis上限10w/s QPS
2. redis集群提高并发能力
## 分布式锁 `参考附录3`
### 一、为什么要使用分布式锁？
### 二、分布式锁需要具备的条件
### 三、分布式锁的三种实现方式
1. 基于数据库的实现方式
2. 基于Redis的实现方式
3. 基于zookeeper的实现方式
### 四、三种方式对比
## 分布式事务 `参考附录4`
### 一、两阶段提交（2PC）
1. 两阶段
2. 具体流程
3. 存在的问题
### 二、三阶段提交（3PC）
1. 三阶段
2. 具体流程
3. 总结
### 三、补偿事务（TCC）
1. TCC
2. 优缺点
### 四、本地消息表（异步确保）
### 五、消息事务
### 六、最大努力通知
### 七、总结
## 分布式Session `参考附录5`
### 一、基于客户端cookie存储
### 二、基于session绑定
### 三、基于session复制
### 四、基于session共享（重点redis）
1、基于Redis持久化session（重点）
2、基于memcached持久化session
3、基于数据库持久化session
## 分布式框架
### 第1章 常用的RPC框架 1
1.1 RPC框架原理 1
1.2 RMI介绍 2
1.2.1 原生RMI代码示例 3
1.2.2 RMI穿透防火墙 5
1.3 CXF/Axis2介绍 7
1.3.1 CXF介绍 7
1.3.2 Axis2介绍 14
1.4 Thrift介绍 21
1.4.1 Thrift工作原理介绍 23
1.4.2 Thrift IDL语法说明 26
1.4.3 基于Apache Thrift的Java版完整案例 28
1.4.4 基于Java注解的简化实现 36
1.5 gRPC介绍 42
1.5.1 protobuf3语法介绍 43
1.5.2 gRPC使用示例 45
1.6 HTTP Client介绍 53
1.6.1 构建HttpClient对象 54
1.6.2 构建URI对象 55
1.6.3 构建请求对象（HttpGet、HttpPost） 56
1.6.4 HttpClient发起调用及获取调用返回结果 56
1.7 实现自己的RPC框架 61
1.8 RPC框架与分布式服务框架的区别 68
1.9 本章小结 68
### 第2章 分布式服务框架总体架构与功能 69
2.1 面向服务的体系架构（SOA） 69
2.1.1 面向服务架构范式 69
2.1.2 服务拆分原则 71
2.2 分布式服务框架现实需求 72
2.3 分布式服务框架总体架构及所需的技术概述 72
2.4 本章小结 74
### 第3章 分布式服务框架序列化与反序列化实现 75
3.1 序列化原理及常用的序列化介绍 75
3.2 Java默认的序列化 77
3.3 XML序列化框架介绍 80
3.4 JSON序列化框架介绍 82
3.5 Hessian序列化框架介绍 87
3.6 protobuf序列化框架介绍 88
3.7 protostuff序列化框架介绍 93
3.8 Thrift序列化框架介绍 98
3.9 Avro序列化框架介绍 100
3.9.1 Avro介绍 100
3.9.2 Avro IDL语言介绍 101
3.9.3 Schema定义介绍 103
3.9.4 Maven配置及使用IDL与Schema自动生成代 103
3.9.5 Avro序列化/反序列化实现 105
3.10 JBoss Marshalling序列化框架介绍 110
3.11 序列化框架的选型 112
3.12 实现自己的序列化工具引擎 113
3.13 本章小结 118
#### 第4章 实现分布式服务框架服务的发布与引入 119
4.1 Spring Framework框架概述 119
4.1.1 Spring Framework介绍 119
4.1.2 Spring Framework周边生态项目介绍 121
4.2 FactoryBean的秘密 122
4.2.1 FactoryBean的作用及使用场景 123
4.2.2 FactoryBean实现原理及示例说明 124
4.3 Spring框架对于已有RPC框架集成的支持 127
4.3.1 Spring支持集成RPC框架介绍 127
4.3.2 基于RmiProxyFactoryBean 实现RMI与Spring的集成 128
4.3.3 基于
HttpInvokerProxyFactoryBean实现HTTP Invoker与Spring的集成 131
4.3.4 基于HessianProxyFactoryBean实现Hessian与Spring的集成 133
4.4 实现自定义服务框架与Spring的集成 136
4.4.1 实现远程服务的发布 136
4.4.2 实现远程服务的引入 144
4.5 在Spring中定制自己的XML标签 150
4.6 本章小结 158
#### 第5章 分布式服务框架注册中心 159
5.1 服务注册中心介绍 159
5.2 ZooKeeper实现服务的注册中心原理 161
5.2.1 ZooKeeper介绍 161
5.2.2 部署ZooKeeper 161
5.2.3 ZkClient使用介绍 164
5.2.4 ZooKeeper实现服务注册中心 173
5.3 集成ZooKeeper实现自己的服务注册与发现 175
5.3.1 服务注册中心服务提供方 175
5.3.2 服务注册中心服务消费方 176
5.3.3 服务注册中心实现 178
5.4 本章小结 189
#### 第6章 分布式服务框架底层通信实现 190
6.1 Java I/O模型及I/O类库的进化 190
6.1.1 Linux下实现的I/O模型 190
6.1.2 Java语言实现的I/O模型 194
6.1.3 Java Classic I/O（Blocking I/O）介绍 194
6.1.4 Java Non-blocking I/O（NIO）介绍 211
6.1.5 NIO2及Asynchronous I/O介绍 233
6.2 Netty使用介绍 255
6.2.1 Netty开发入门 256
6.2.2 Netty粘包/半包问题解决 265
6.3 使用Netty构建服务框架底层通信 320
6.3.1 构建分布式服务框架Netty服务端 320
6.3.2 构建分布式服务框架服务调用端Netty客户端 330
6.4 本章小结 347
#### 第7章 分布式服务框架软负载实现 348
7.1 软负载的实现原理 348
7.2 负载均衡常用算法 349
7.2.1 软负载随机算法实现 349
7.2.2 软负载加权随机算法实现 350
7.2.3 软负载轮询算法实现 351
7.2.4 软负载加权轮询算法实现 352
7.2.5 软负载源地址hash算法实现 354
7.3 实现自己的软负载机制 355
7.4 软负载在分布式服务框架中的应用 357
7.5 本章小结 361
#### 第8章 分布式服务框架服务治理 362
8.1 服务治理介绍 362
8.2 服务治理的简单实现 364
8.2.1 服务分组路由实现 364
8.2.2 简单服务依赖关系分析实现 374
8.2.3 服务调用链路跟踪实现原理 380
8.3 本章小结 380
## 参考资料
- 附录1：(
https://blog.csdn.net/shipfei_csdn/article/details/109502565)
- 附录2：(
https://blog.csdn.net/shipfei_csdn/article/details/109502592)
- 附录3：(2021最新Java面经整理 | 分布式篇（三）分布式锁)
- 附录4：(
https://blog.csdn.net/shipfei_csdn/article/details/109510159)
- 附录5：(
https://blog.csdn.net/shipfei_csdn/article/details/109513378)
- 附录6：《架构探险：从零开始写分布式服务框架》
页:
[1]