掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 版權信息
- ISBN：9787111710226
- 條形碼：9787111710226 ; 978-7-111-71022-6
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 本書特色
適讀人群 ：所有開發工程師都需要看這本書，因為分布式系統無處不在，每一個開發工程師都應該了解分布式系統的底層支撐——分布式協議和算法。（1）作者背景：作者先后就職于Intel、騰訊等互聯網大廠，擔任重要工作。 （2）作者經驗豐富：作者在大規模分布式系統領域有10余年工作經驗，曾擔任騰訊QQ后端基礎設施技術負責人。 （3）理論直指核心：深刻、詳細剖析分布式的4大基礎理論和10種常用協議和算法，幫助讀者透徹理解分布式的本質和精髓。 （4）實戰工程落地：通過10余個小案例和3大綜合案例，詳細演示了如何在工程實踐中將分布式的基礎理論和協議與算法落地。 （5）12位專家推薦：來自騰訊、華為、阿里等企業的12位專家高度評價并一致推薦。
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 內容簡介
本書是一本以實戰為導向、系統講解分布式協議與算法、深刻揭示分布式系統精髓與本質的著作。作者以自己在騰訊和lntel的多年分布式系統工程經驗為基礎，用圖文并茂、通俗易懂的方式詳細講解了分布式的基礎理論、協議、算法，以及它們如何在工程實戰中落地。
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 目錄
【理論篇】
第1章 拜占庭將軍問題2
1.1 什么是拜占庭將軍問題2
1.1.1 蘇秦的困境3
1.1.2 二忠一叛難題3
1.2 口信消息，我們該如何處理呢5
1.3 如何解決n>(3f +1)的限制8
1.3.1 什么是簽名消息8
1.3.2 簽名消息型拜占庭問題之解10
1.4 拜占庭容錯算法和非拜占庭容錯算法，該如何選擇呢16
1.5 本章小結17
第2章 CAP理論19
2.1 CAP理論：分布式系統的ph試紙，用它來測酸堿度20
2.1.1 CAP三指標20
2.1.2 CAP不可能三角24
2.1.3 如何使用CAP理論25
2.2 ACID理論：CAP的“酸”，追求一致性28
2.2.1 二階段提交協議30
2.2.2 TCC32
2.3 BASE理論：CAP的“堿”，追求可用性35
2.3.1 實現基本可用的4板斧36
2.3.2 終一致性37
2.3.3 如何使用BASE理論39
2.4 本章小結40
【協議與算法篇】
第3章 Paxos算法44
3.1 Basic Paxos：如何在多個節點間確定某變量的值45
3.1.1 你需要了解的3種角色46
3.1.2 如何達成共識48
3.2 Multi-Paxos：Multi-Paxos不是一個算法，而是統稱52
3.2.1 蘭伯特關于Multi-Paxos的思考53
3.2.2 Chubby是如何實現Multi-Paxos算法的55
3.3 本章小結58
第4章 Raft算法59
4.1 Raft是如何選舉領導者的60
4.1.1 有哪些成員身份60
4.1.2 選舉領導者的過程61
4.1.3 選舉過程四連問64
4.2 Raft是如何復制日志的68
4.2.1 如何理解日志68
4.2.2 如何復制日志69
4.2.3 如何實現日志的一致性71
4.3 Raft是如何解決成員變更問題的73
4.3.1 成員變更問題74
4.3.2 如何通過單節點變更解決成員變更問題75
4.4 Raft與一致性79
4.5 本章小結80
第5章 一致哈希算法82
5.1 使用哈希算法有什么問題83
5.2 如何使用一致哈希算法實現哈希尋址85
5.3 本章小結90
第6章 ZAB協議92
6.1 如何實現操作的順序性93
6.1.1 為什么Multi-Paxos無法保證操作的順序性93
6.1.2 ZAB協議是如何實現操作的順序性的97
6.2 主節點崩潰了，怎么辦101
6.2.1 ZAB協議是如何選舉領導者的101
6.2.2 ZooKeeper是如何選舉領導者的107
6.3 如何從故障中恢復111
6.3.1 ZAB集群如何從故障中恢復112
6.3.2 ZooKeeper如何從故障中恢復119
6.4 ZAB協議：如何處理讀寫請求125
6.4.1 ZooKeeper處理讀寫請求的原理126
6.4.2 ZooKeeper處理讀寫請求的代碼實現127
6.5 ZAB協議與Raft算法134
6.6 本章小結136
第7章 Gossip協議137
7.1 Gossip的三板斧138
7.2 如何使用反熵實現終一致性141
7.3 本章小結144
第8章 Quorum NWR算法145
8.1 Quorum NWR的三要素146
8.2 如何實現Quorum NWR149
8.3 本章小結150
第9章 MySQL XA151
9.1 什么是XA規范152
9.2 如何通過MySQL XA實現分布式事務155
9.3 本章小結157
第10章 TCC158
10.1 什么是TCC159
10.2 如何通過TCC實現指令執行的原子性161
10.3 本章小結163
第11章 PBFT算法165
11.1 口信消息型拜占庭問題之解的局限166
11.2 PBFT算法是如何達成共識的167
11.3 如何替換作惡的主節點171
11.3.1 主節點作惡會出現什么問題171
11.3.2 如何替換作惡的主節點172
11.4 PBFT算法的局限、解決辦法和應用176
11.5 本章小結177
第12章 PoW算法178
12.1 如何理解工作量證明179
12.2 區塊鏈是如何實現PoW算法的181
12.3 本章小結183
【實戰篇】
第13章 InfluxDB企業版一致性實現剖析186
13.1 什么是時序數據庫186
13.2 如何實現META節點一致性188
13.3 如何實現DATA節點一致性188
13.3.1 自定義副本數188
13.3.2 Hinted-handoff189
13.3.3 反熵190
13.3.4 Quorum NWR191
13.4 本章小結192
第14章 Hashicorp Raft194
14.1 如何跨過理論和代碼之間的鴻溝195
14.1.1 Hashicorp Raft如何實現領導者選舉195
14.1.2 Hashicorp Raft如何復制日志201
14.2 如何以集群節點為中心使用API205
14.2.1 如何創建Raft節點205
14.2.2 如何增加集群節點208
14.2.3 如何移除集群節點209
14.2.4 如何查看集群節點狀態210
14.3 本章小結211
第15章 基于Raft的分布式KV系統開發實戰213
15.1 如何設計架構214
15.1.1 如何設計接入協議215
15.1.2 如何設計KV操作216
15.1.3 如何實現分布式集群218
15.2 如何實現代碼220
15.2.1 如何實現接入協議220
15.2.2 如何實現KV操作222
15.2.3 如何實現分布式集群224
15.3 本章小結229
展開全部
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 節選
序 Foreword 一晃兩年多過去了，之前寫稿的點點滴滴猶在昨天，忙碌、充實、快樂。比如，為了交付更高質量的技術內容，我總是會有很多想法，偶爾會周末通宵寫稿，核對每句話、每個細節。 借著新書出版的這個機會，和大家聊聊我*近忙的一些事情和思考。 因為一直從事互聯網后臺、云計算的相關工作，我一直在關注著基礎技術的演進和發展，尤其是與分布式、微服務、大數據相關的技術的發展，在我看來，我們現在正處于基礎技術突破性發展的浪潮中。 首先，Serverless時代已來，相當一部分業務系統已經基于Serverless實現，這不僅降低了對項目人員的專業能力的要求，而且提高了整體的研發效能。如果大家還在猶豫Serverless（或FaaS）能否支撐起大系統，那么我這里簡單舉個具體案例證明。我之前負責的QQ后臺的微服務能力就是由一個框架和幾個API實現的，通過這幾個API就支撐起QQ后臺海量、復雜的系統，所以Serverless支撐大系統是沒問題的。 其次，我覺得承載實時大數據中臺基石能力的時序數據庫只是一個過渡形態的產品。為什么這么說？與元數據不同，時序數據*大的需求不是存儲，而是分析和洞察，但我們在實現分析和洞察時，對系統的查詢性能要求極高。也就是說，大家常說的“時序數據的特點是多寫少讀、成本敏感”其實是不成立的，因“讀”根本就不少，那么，以這個特點為目標來設計的系統也是滿足不了實際場景的需求的。另外，站在分析和洞察的角度，底層應該是一個Serverless的技術底座，支持Metric（指標）、Log（日志）、Trace（追蹤）、Meta data（元數據）等，而不是一個僅僅支持指標的時序數據庫。也就是說，僅僅支持指標的時序數據庫是無法有效支撐分析和洞察的。 然后，云計算的興起令基礎技術發生了很大的變化，而這些變化中*突出的就是“技術要具有成本優勢”。 基于開源軟件，我們很容易“堆砌”一套業務需要的功能。另外，基于大型互聯網后臺（比如QQ）的架構理念，我們也能支撐海量的服務和流量。也就是說，實現功能或支撐海量服務相關的軟件和理念都已經很成熟，但功能背后的成本問題突出。 而成本就是錢，功能背后的成本問題是需要重視和解決的，比如，騰訊自研的KV存儲相比Redis降低了數量級倍數的成本。另外，分布式技術本身就是適用于規模業務的，而且隨著業務規模的增加，成本的痛點會更加突出。所以，我們在設計系統架構時，需要將成本作為一個權衡點考慮進去。 *后，臨淵羨魚，不如退而編碼，讓我們保持好奇心和創新精神，與時間做朋友，學習、成長，腳踏實地地實現自己的技術理想！
分布式協議與算法實戰:攻克分布式系統設計的關鍵難題 作者簡介
作者：韓健資深分布式技術專家，擁有10余年技術研發和管理經驗。曾就職于騰訊（前騰訊QQ后端基礎設施技術負責人）和Intel，從事與大規模分布式系統和云計算相關的工作。在大規模分布式系統領域有非常深厚的積累，擅長分布式、高性能、高并發、高可用的海量服務中間件的架構設計和開發，尤其是與大數據中間件相關的各種技術。在操作系統和計算機網絡領域也有非常豐富的實踐經驗，對Linux內核、TCP/IP等技術有深入的理解。熱衷于技術分享，是FreeTSDB（業界第一個補齊了InfluxDB分布式能力的開源時序數據庫）的發起人和核心貢獻者。極客時間專欄作家，《分布式協議與算法實戰》專欄作者，著有暢銷書《InfluxDB原理與實戰》。維護有微信公眾號influxdb-dev。 技術審校：朱儀姣騰訊資深架構師，騰訊監管業務研發負責人。對分布式設計、海量服務之道、高性能架構設計有深刻的理解和豐富的實戰經驗，主導了萬億級安全監測大數據分析平臺的分布式架構設計和性能優化等項目。
書友推薦
- >
人文閱讀與收藏·良友文學叢書:一天的工作
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
苦雨齋序跋文-周作人自編集
- >
推拿
- >
李白與唐代文化
- >
我與地壇
- >
羅曼·羅蘭讀書隨筆-精裝
- >
姑媽的寶刀
本類暢銷
