JAVA分布式架構完整知識體系
一、分布式理論基礎
1. CAP理論
2. BASE理論
3. 數(shù)據(jù)一致性理論(副本、協(xié)調(diào)者、分布式協(xié)議2PC 3PC、選舉、邏輯時鐘)
4. 數(shù)據(jù)一致性模型
二、分布式緩存
1. 緩存的更新模式
2. 緩存的失效機制
3. 緩存的淘汰策略
4. 緩存穿透、緩存擊穿、緩存雪崩
5. 緩存設計時幾個需要關注的點
6. 緩存中的熱key和大value問題
三、分布式鎖
1. 為什么要使用分布式鎖？
2. 分布式鎖需要具備的條件
3. 分布式鎖的三種實現(xiàn)方式
4. 三種方式對比
四、分布式事務
1. 兩階段提交（2PC）
2. 三階段提交（3PC）
3. 補償事務（TCC）
4. 本地消息表（異步確保）
5. 消息事務
6. 最大努力通知
7. 總結
五、分布式Session
六、從零開始寫分布式服務框架
1. 第1章 常用的RPC框架 1
2. 第2章 分布式服務框架總體架構與功能 69
3. 第3章 分布式服務框架序列化與反序列化實現(xiàn) 75
4. 第4章 實現(xiàn)分布式服務框架服務的發(fā)布與引入 119
5. 第5章 分布式服務框架注冊中心 159
6. 第6章 分布式服務框架底層通信實現(xiàn) 190
7. 第7章 分布式服務框架軟負載實現(xiàn) 348
8. 第8章 分布式服務框架服務治理 362
## 分布式理論基礎
### 一、CAP理論
CAP理論是指在一個分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可兼得。
1. `C (Consistency)，一致性`：數(shù)據(jù)在分布式系統(tǒng)中的多個副本之間保持一致的特性。在數(shù)據(jù)一致的某個時間點，執(zhí)行更新操作后，也要求系統(tǒng)各部分數(shù)據(jù)是一致的。
2. `A (Availability)，可用性`：服務隨時可用，即使某些節(jié)點發(fā)生故障也不影響集群的對外服務。
3. `P (Partition)，分區(qū)容錯性`：分區(qū)容錯性約束了分布式系統(tǒng)在遭遇任何網(wǎng)絡分區(qū)后（部分網(wǎng)絡分區(qū)故障），仍要對外提供一致性和可用性的服務。（注：網(wǎng)絡分區(qū)，即在分布式系統(tǒng)內(nèi)，不同節(jié)點歸屬在不同網(wǎng)絡子網(wǎng)，子網(wǎng)絡之間可能出現(xiàn)網(wǎng)絡不連通情況，但在子網(wǎng)內(nèi)部的通信是正常的。）
### 二、BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP理論中一致性（A）和可用性（C）權衡的結果，來源于對大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實踐的結論。
1. BA (Basically Available) ，基本可用：分布式系統(tǒng)出現(xiàn)故障時，允許損失部分可用性，保證核心可用。
2. S (Soft state) ，軟狀態(tài)：系統(tǒng)中的節(jié)點數(shù)據(jù)允許存在中間狀態(tài)，該中間狀態(tài)的存在不會影響到整體的可用性，這通常體現(xiàn)在數(shù)據(jù)在一致性同步復制過程中，允許存在延時。
3. E (Eventually consistent)，最終一致性：系統(tǒng)中所有數(shù)據(jù)副本經(jīng)過一段時間同步后，最終能夠達到一致的狀態(tài)。
### 三、數(shù)據(jù)一致性理論(副本、協(xié)調(diào)者、分布式協(xié)議2PC 3PC、選舉、邏輯時鐘)
#### 1. 數(shù)據(jù)一致性問題
?1. `消息傳遞異步無序`: 現(xiàn)實網(wǎng)絡不是一個可靠的信道，存在消息延時、丟失，節(jié)點間消息傳遞做不到同步有序。
?2. `節(jié)點宕機`: 節(jié)點持續(xù)宕機，不會恢復。
?3. `節(jié)點宕機恢復`: 節(jié)點宕機一段時間后恢復，在分布式系統(tǒng)中最常見。
?4. `網(wǎng)絡分化`: 網(wǎng)絡鏈路出現(xiàn)問題，將N個節(jié)點隔離成多個部分。
?5. `拜占庭將軍問題`：節(jié)點或宕機或邏輯失敗，甚至不按套路出牌拋出干擾決議的信息。
#### 2. 副本
1. 當前一般通過復制技術進行分布式系統(tǒng)的一致性的保證
2. 不同的數(shù)據(jù)節(jié)點由于網(wǎng)絡延遲、操作鏈中一環(huán)失敗等原因，往往造成數(shù)據(jù)不一致的問題。
#### 2. 協(xié)調(diào)者
* 分布式事務中通知和協(xié)調(diào)數(shù)據(jù)庫提交或回滾的角色
#### 3. 分布式協(xié)議（2PC、3PC）
常見的分布式協(xié)議有：2PC（兩階段提交）、3PC（三階段提交）,他們也不能根除數(shù)據(jù)不一致性問題。
1. 2PC（兩階段提交）：我們將提議的節(jié)點稱為協(xié)調(diào)者(coordinator)，其他參與決議節(jié)點稱為參與者(participants, 或cohorts)。
?1. `準備階段(投票階段)，PreCommit`。協(xié)調(diào)者發(fā)起一個提議，分別問詢各參與者是否接受。
?2. `提交階段（執(zhí)行階段），doCommit`。協(xié)調(diào)者根據(jù)參與者的反饋，提交或中止事務，如果參與者全部同意則提交，只要有一個參與者不同意就中止。
2. 3PC（三階段提交）
3PC是2PC的改進版本，引入了超時機制，加入一個新的CanCommit階段。
?1. CanCommit階段：協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
1. `事務詢問`：協(xié)調(diào)者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務提交操作。然后開始等待參與者的響應。
2. `響應反饋`：參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執(zhí)行事務，則返回Yes響應，并進入預備狀態(tài)。否則反饋No
?2. PreCommit階段：協(xié)調(diào)者根據(jù)參與者CanCommit階段的反應情況來決定是否可以記性事務的PreCommit操作。若獲得no響應，則中斷 1. `事務`；若獲得yes響應，則，
發(fā)送預提交請求：協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進入Prepared階段。
2. `事務預提交`：參與者接收到PreCommit請求后，會執(zhí)行事務操作，并將undo和redo信息記錄到事務日志中。
3. `響應反饋`：如果參與者成功的執(zhí)行了事務操作，則返回ACK響應，同時開始等待最終指令。
?3. DoCommit階段：該階段進行真正的事務提交，若沒有收到ACK響應則中斷事務、回滾；若收到ACK響應，則，
1. `發(fā)送提交請求`：協(xié)調(diào)接收到參與者發(fā)送的ACK響應，那么他將從預提交狀態(tài)進入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求。
2. `事務提交`：參與者接收到doCommit請求之后，執(zhí)行正式的事務提交。并在完成事務提交之后釋放所有事務資源。
3. `響應反饋`：事務提交完之后，向協(xié)調(diào)者發(fā)送Ack響應。
4. `完成事務`：協(xié)調(diào)者接收到所有參與者的ack響應之后，完成事務。
4. 選舉、多數(shù)派、租約
?1. 選舉
1. `Bully算法`：每個節(jié)點對應一個序號，序號最高的節(jié)點為leader。leader宕機后次高序號的節(jié)點被重選為leader。2. 缺點：網(wǎng)絡分化情況下，將產(chǎn)生多個leader
?2. 多數(shù)派
1. `原理`：多數(shù)派的原理說起來很簡單，假如節(jié)點總數(shù)為2f+1，則一項決議得到多于 f 節(jié)點贊成則獲得通過。
2. `優(yōu)點`：避免多個leader
?3. 租約
1. `原理`：中心思想是每次租約時長內(nèi)只有一個節(jié)點獲得租約、到期后必須重新頒發(fā)租約
2. `優(yōu)點`：租約機制確保了一個時刻最多只有一個leader，避免只使用心跳機制產(chǎn)生雙主的問題，`如Zookpeer`
?5. 邏輯時鐘-參考 `參考附錄1`
### 四、數(shù)據(jù)一致性模型 `參考附錄1`
1、強一致性
2、弱一致性
3、最終一致性
4、最終一致性模型的變種
## 分布式緩存
### 一、緩存的更新模式 `參考附錄2`
1. Cache Aside 模式（重點，主流）
1. 原理：緩存更新時先更新數(shù)據(jù)庫，然后在讓緩存失效
2. 流程
?1. `命中`：應用程序從 cache 中取數(shù)據(jù)，取到后返回。
?2. `失效`：應用程序先從 cache 取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)，成功后，放到緩存中。
?3. `更新`：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效。
3. 常見問題：
?1. `先更新數(shù)據(jù)庫，再更新緩存`：兩個并發(fā)的寫操作導致臟數(shù)據(jù)
?2. `先刪除緩存，再更新數(shù)據(jù)庫`：兩個并發(fā)的讀和寫操作導致臟數(shù)據(jù)
?3. `先更新數(shù)據(jù)庫，再刪除緩存`：在線程1查詢數(shù)據(jù)庫到寫入緩存之間（磁盤IO幾ms），線程2將寫入數(shù)據(jù)庫并且刪除緩存，導致線程1寫入緩存的數(shù)據(jù)還是舊的數(shù)據(jù)庫數(shù)據(jù)。
2. Read/Write Through 模式
1. 在Read/Write Through 模式中，緩存代理了DB讀取、寫入的邏輯，可以把緩存看成唯一的存儲。先更新緩存，緩存負責同步更新數(shù)據(jù)庫。
2. Read Through： 模式就是在查詢操作中更新緩存，也就是說，當緩存失效的時候，Cache Aside 模式是由調(diào)用方負責把數(shù)據(jù)加載入緩存，而 Read Through 則用緩存服務自己來加載。
3. Write Through 模式和 Read Through 相仿，不過是在更新數(shù)據(jù)時發(fā)生。當有數(shù)據(jù)更新的時候，如果沒有命中緩存，直接更新數(shù)據(jù)庫，然后返回。如果命中了緩存，則更新緩存，然后由緩存自己更新數(shù)據(jù)庫（這是一個同步操作）。
3. Write Behind Caching模式
* 這種模式下所有的操作都走緩存，緩存里的數(shù)據(jù)再通過異步的方式同步到數(shù)據(jù)庫里面。所以系統(tǒng)的寫性能能夠大大提升。
4. 三種模式總結
1. Cache Aside 更新模式簡單
2. Read/Write Through 更新模式只需要維護緩存
3. Write Behind Caching 更新模式異步，處理并發(fā)高，但犧牲了強一致性
4. 緩存一定要合理的設置過期時間
### 二、緩存的失效機制 `參考附錄2`
1. 主動失效
2. 被動失效
### 三、緩存的淘汰策略 `參考附錄2`
1. LRU
2. LFU
3. FIFO
### 四、緩存穿透、緩存擊穿、緩存雪崩 `參考附錄2`
1. 緩存穿透
2. 緩存擊穿
3. 緩存雪崩
### 五、緩存設計時幾個需要關注的點 `參考附錄2`
1. 不要把所有的數(shù)據(jù)都加載到緩存中。
2. 緩存需要有一個失效機制。
3. 緩存的代價是犧牲了數(shù)據(jù)的強一致性。
### 六、緩存中的熱key和大value問題 `參考附錄2`
1. 在分布式緩存中，面對高并發(fā)要求有兩個問題非常重要：熱key問題（hot key）和大value（big value）問題。
?1. 熱key問題：是指緩存集群中的某個key在瞬間被數(shù)萬甚至十萬的并發(fā)請求打爆。
?2. 大value問題：是指某個key對應的value可能有gb級別的大小，導致查詢value的時候會引發(fā)網(wǎng)絡相關的故障問題。
2. 熱key問題定義
1. 熱key問題是指：突然有幾十萬甚至更大的請求去訪問redis上的某個特定key。這樣會造成流量過于集中，達到Redis單實例瓶頸（一般是10W QPS級別），或者物理網(wǎng)卡上限，從而導致這臺redis的服務器Hold不住，直到緩存服務器垮掉。
2. 發(fā)現(xiàn)熱key
?1. 按業(yè)務場景，預估熱點key（常用）
?2. 客戶端收集（常用）
?3. 代理層收集
?4. redis監(jiān)控命令（常用）
?5. 網(wǎng)絡抓包分析
?6. 基于大數(shù)據(jù)流式計算技術的緩存熱點自動發(fā)現(xiàn)
3. 解決方案
4. 總結
?1. 每臺redis上限10w/s QPS
?2. redis集群提高并發(fā)能力
## 分布式鎖 `參考附錄3`
### 一、為什么要使用分布式鎖？
### 二、分布式鎖需要具備的條件
### 三、分布式鎖的三種實現(xiàn)方式
1. 基于數(shù)據(jù)庫的實現(xiàn)方式
2. 基于Redis的實現(xiàn)方式
3. 基于zookeeper的實現(xiàn)方式
### 四、三種方式對比
## 分布式事務 `參考附錄4`
### 一、兩階段提交（2PC）
1. 兩階段
2. 具體流程
3. 存在的問題
### 二、三階段提交（3PC）
1. 三階段
2. 具體流程
3. 總結
### 三、補償事務（TCC）
1. TCC
2. 優(yōu)缺點
### 四、本地消息表（異步確保）
### 五、消息事務
### 六、最大努力通知
### 七、總結
## 分布式Session `參考附錄5`
### 一、基于客戶端cookie存儲
### 二、基于session綁定
### 三、基于session復制
### 四、基于session共享（重點redis）
1、基于Redis持久化session（重點）
2、基于memcached持久化session
3、基于數(shù)據(jù)庫持久化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注解的簡化實現(xiàn) 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發(fā)起調(diào)用及獲取調(diào)用返回結果 56
1.7 實現(xiàn)自己的RPC框架 61
1.8 RPC框架與分布式服務框架的區(qū)別 68
1.9 本章小結 68
### 第2章 分布式服務框架總體架構與功能 69
2.1 面向服務的體系架構（SOA） 69
2.1.1 面向服務架構范式 69
2.1.2 服務拆分原則 71
2.2 分布式服務框架現(xiàn)實需求 72
2.3 分布式服務框架總體架構及所需的技術概述 72
2.4 本章小結 74
### 第3章 分布式服務框架序列化與反序列化實現(xiàn) 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序列化/反序列化實現(xiàn) 105
3.10 JBoss Marshalling序列化框架介紹 110
3.11 序列化框架的選型 112
3.12 實現(xiàn)自己的序列化工具引擎 113
3.13 本章小結 118
#### 第4章 實現(xiàn)分布式服務框架服務的發(fā)布與引入 119
4.1 Spring Framework框架概述 119
4.1.1 Spring Framework介紹 119
4.1.2 Spring Framework周邊生態(tài)項目介紹 121
4.2 FactoryBean的秘密 122
4.2.1 FactoryBean的作用及使用場景 123
4.2.2 FactoryBean實現(xiàn)原理及示例說明 124
4.3 Spring框架對于已有RPC框架集成的支持 127
4.3.1 Spring支持集成RPC框架介紹 127
4.3.2 基于RmiProxyFactoryBean 實現(xiàn)RMI與Spring的集成 128
4.3.3 基于
HttpInvokerProxyFactoryBean實現(xiàn)HTTP Invoker與Spring的集成 131
4.3.4 基于HessianProxyFactoryBean實現(xiàn)Hessian與Spring的集成 133
4.4 實現(xiàn)自定義服務框架與Spring的集成 136
4.4.1 實現(xiàn)遠程服務的發(fā)布 136
4.4.2 實現(xiàn)遠程服務的引入 144
4.5 在Spring中定制自己的XML標簽 150
4.6 本章小結 158
#### 第5章 分布式服務框架注冊中心 159
5.1 服務注冊中心介紹 159
5.2 ZooKeeper實現(xiàn)服務的注冊中心原理 161
5.2.1 ZooKeeper介紹 161
5.2.2 部署ZooKeeper 161
5.2.3 ZkClient使用介紹 164
5.2.4 ZooKeeper實現(xiàn)服務注冊中心 173
5.3 集成ZooKeeper實現(xiàn)自己的服務注冊與發(fā)現(xiàn) 175
5.3.1 服務注冊中心服務提供方 175
5.3.2 服務注冊中心服務消費方 176
5.3.3 服務注冊中心實現(xiàn) 178
5.4 本章小結 189
#### 第6章 分布式服務框架底層通信實現(xiàn) 190
6.1 Java I/O模型及I/O類庫的進化 190
6.1.1 Linux下實現(xiàn)的I/O模型 190
6.1.2 Java語言實現(xiàn)的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開發(fā)入門 256
6.2.2 Netty粘包/半包問題解決 265
6.3 使用Netty構建服務框架底層通信 320
6.3.1 構建分布式服務框架Netty服務端 320
6.3.2 構建分布式服務框架服務調(diào)用端Netty客戶端 330
6.4 本章小結 347
#### 第7章 分布式服務框架軟負載實現(xiàn) 348
7.1 軟負載的實現(xiàn)原理 348
7.2 負載均衡常用算法 349
7.2.1 軟負載隨機算法實現(xiàn) 349
7.2.2 軟負載加權隨機算法實現(xiàn) 350
7.2.3 軟負載輪詢算法實現(xiàn) 351
7.2.4 軟負載加權輪詢算法實現(xiàn) 352
7.2.5 軟負載源地址hash算法實現(xiàn) 354
7.3 實現(xiàn)自己的軟負載機制 355
7.4 軟負載在分布式服務框架中的應用 357
7.5 本章小結 361
#### 第8章 分布式服務框架服務治理 362
8.1 服務治理介紹 362
8.2 服務治理的簡單實現(xiàn) 364
8.2.1 服務分組路由實現(xiàn) 364
8.2.2 簡單服務依賴關系分析實現(xiàn) 374
8.2.3 服務調(diào)用鏈路跟蹤實現(xiàn)原理 380
8.3 本章小結 380
需要的小伙伴私信（111）即可
