【分享說明】：
我會花很多時間或淺或深的研讀一本書，然後總結一些提煉出來的精華，用簡短的語言，讓其他人能夠用很少的時間大致知道這本書能帶給自己的價值，如果適用自己，鼓勵買一本正本實體書細讀和收藏。
通篇會以原文目錄爲結構，給出提煉內容，如果不重要或者一看目錄就懂的，會保留目錄，有不明白的，以原文學習爲參照。
所有分享內容，爲了區分，會以》開頭，可能有多行縮進，或差異化顏色表示。
【書名】：《分佈式實時處理系統 原理、架構與實現》
【作者】：盧譽聲，Autodesk（全球很大的軟件公司）系統軟件研發工程師，從事平臺架構方面的研發工作。通過全文來看，作者在大數據框架方面，尤其是storm，做了很深入的研究。
【發行】：2016年
【適用】：大數據行業從業務者，希望借鑑別人經驗的，希望手把手實現一個分佈式計算框架的。想學習完整知識體系的不適用。
【總結】：
1、作者談不上是專業的研究人員，全文更像是一個總結和分享。
2、前面以storm等鋪墊了很多知識背景，彙總借鑑爲主，有點像論文。後面從0實現一個分佈式框架，很細緻。
3、全文融匯了較強的工作經驗分享，storm等大數據從業者，可以吸取不少的經驗，後文在AWS和阿里部署都考慮到可見一斑。
4、經驗有餘但知識體系不健全是本書的不足，不適用於做教材，也不太適用於0基礎人員。
5、全文實踐細節很到位，讀一遍之後，很需要抽時間跟着作者的代碼，邊讀邊實踐一回。
【章節總結】
第1章介紹了分佈式相關的一些理論知識，分享了幾個常用框架
2-3章論文似的介紹了網絡通信和分佈式通信技術，有經驗的忽略。
4章鋪墊了c++，故事模式的把c++開發相關的技術都貫穿起來，有所偏離，但非常贊，強烈建議c++中低級從業者完整看一遍。
5章介紹storm等框架的一些實現細節，看一下，這個是後續實踐的基礎。
6-14以stom框架爲參考，自行實現了一個分佈式計算框架Hurricane，比stom更猛烈的風，命名有意思。
15-16章以具體的需求爲例，應用了Hurricane，想收穫實踐經驗的值得看一遍。
17章AWS和阿里雲部署，由於框架是自實現的，相當於使用雲主機，偏運維。
【正式分享】
注：由於作者偏實踐，分享內容融入一些我個人的解釋和補填的信息，原文找不到的。我自己已經有一些相關知識背景，初學者可能需要看的再仔細一些。
序一
序二
序三
前言
第1章分佈式計算概述1
1.1分佈式概念1
1.2分佈式計算及其原理2
》一般3步:
設計分佈式模型：拆分、通信、彙總
分佈式任務分配算法
編寫分佈式執行程序
1.3分佈式系統特性3
1.3.1容錯性3
》多指節點故障而非代碼錯誤
1.3.2高可擴展性4
》動態增減功能和資源
1.3.3開放性5
》系統集成能力
1.3.4併發處理能力5
》CAP，一致性，可用性，分區容錯
1.3.5透明性6
》內部細節外部不可見
1.4通用分佈式計算系統6
1.4.1ApacheHadoop6
》特性
高可靠
高可擴展，自動負載均衡
高效，並行讀取數據
高容錯，冗餘存儲數據
低成本，開源免費
注：HDFS非高實時，MapReduce基於HDFS
1.4.2ApacheSpark8
》特點
執行速度極快，數據存儲於內存而不是HDFS
支持多種數據模式，數據源豐富
更多通用計算模型（SQL接口、流模型、機器學習、GraphX圖片計算等接口）
注：Spark是任務式的，非實時
1.4.3ApacheStorm9
》特點
高可擴展
高容錯性（重試）
易於管理：ZooKeepe
消息可靠性
1.5分佈式存儲系統10
1.5.1分佈式存儲概念10
》NoSQL優缺點：
模式相對自由，沒有嚴格的限定，這也導致維護數據有效性困難
數據一致性和事務性較弱，依賴於上層邏輯保障
查詢與關聯有限，上層邏輯解決
讀寫性能問題：一般寫入快，Cassandra寫很快，讀相對慢。MongoDB複雜索引較慢
1.5.2分佈式存儲系統特點12
》高性能、高可擴展（節點）、成本低（廉價設備）
1.5.3分佈式存儲系統分類12
》列存儲：HBase、Cassandra
》文檔型存儲（整體存儲）：MongoDB、CoudhDB
》圖型存儲：典型的是Neo4j，節點之間互通，可以快速檢索
》健值對（KV）存儲：redis、riak
》分佈式文件系統：
1.5.4常見分佈式存儲系統13
》HBase架構：
Zookeeper：集羣管理
HMaster：集羣控制者
HRegionServer：集羣數據節點
HDFS：底層文件系統
》Cassandra特點
模式靈活
無單點故障：沒有主節點
可擴展性（相對資源）
》MongoDB：BSON數據存儲格式
1.6本章小結14
第2章分佈式系統通信基礎15
》非常基礎的網絡知識，跳過
2.1時代的浪潮15
2.1.1集中式通信網16
2.1.2去中心化16
2.2可靠的數據鏈路17
2.2.1數據分組17
2.2.2幀同步18
2.2.3差錯控制18
2.2.4鏈路管理18
2.2.5問題與解決方案19
2.3分層架構19
2.4網絡層22
2.4.1尋找路徑22
2.4.2網絡分層23
2.4.3TCP/IP概述23
2.4.4IP協議24
2.5傳輸層30
2.5.1數據自動分包30
2.5.2端到端的傳輸30
2.5.3數據的可靠傳輸30
2.6應用層35
2.6.1ping35
2.6.2telnet36
2.6.3OSPF36
2.6.4DNS36
2.6.5HTTP協議37
2.7基於消息協議的公告牌38
2.7.1需求描述38
2.7.2制定協議38
2.8分佈式通信舉例——MapReduce39
》MR的通信機制是讀寫操作共享的HDFS
》HDFS的基本原則是：NameNode管理數據存儲信息，DataNode存數據，操作數據請求到NameNode，NameNode分發給DataNode處理
2.9本章小結41
第3章通信系統高層抽象42
》非常基礎的概念知識，跳過
3.1RPC介紹42
3.2RESTful44
》看了好幾遍，沒懂，上網查出好多信息，也沒懂，綜合所有資料，自己總結如下：
1、REST的核心是一種資源視角，不再是操作視角。比如我要查詢餘額，理解爲餘額是資源，我的做的是是“GET”
2、資源擁有很多狀態，對數據的修改理解爲狀態的轉換，你如不是要“存錢”，而是”修改 餘額“。
3、符合上以設計風格的就是RESTfull。
例如：
GET /user/info
DEL /user/info
和
/user/getinfo
/user/delinfo
前者是，後者不是
3.2.1資源和表現層45
3.2.2狀態轉移45
3.2.3RESTful總結46
3.3消息隊列46
3.4序列化49
3.5使用Thrift實現公告牌服務50
3.5.1ApacheThrift介紹51
3.5.2安裝ApacheThrift51
3.5.3編寫Thrift文件52
3.5.4實現服務器53
3.5.5實現客戶端54
3.6本章小結56
第4章走進C高性能編程57
》與分佈式無關，作者用了劇情模式從最初的簡單需求，到最後的實現，貫穿了一個研發工程師日常用到的大部分技術，雖然知識初級，但是非常有意思，讓看似無關的一系列技術點形成了強烈的聯繫，深刻理解一下技術誕生的需求場景，50多頁，這是我見過最詳細的了，如果看一遍目錄有較多不認識或用的少，強烈建議抽時間仔細研讀一遍
4.1基於C的留言板系統58
4.1.1基於Socket的通信58
4.1.2C中的內存與資源管理64
4.2來自服務器的天書69
4.2.1編碼69
4.2.2C98的編碼缺陷72
4.2.3C11編碼支持73
4.3繁忙的服務器75
4.3.1分身乏術75
4.3.2fork——分身術76
4.3.3進程間通信79
4.3.4輕量級分身——線程85
4.3.5C11線程86
4.3.6競爭問題與解決方案88
4.3.7多線程優化95
4.3.8異步I/O99
4.4消失不見的內存105
4.4.1內存分配與內存碎片106
4.4.2tcmalloc108
4.4.3內存池110
4.5本章小結112
第5章分佈式實時處理系統113
5.1Hadoop與MapReduce113
5.1.1HDFS114
》HDFS特點
高容錯性：冗餘存儲
廉價集羣
高吞吐（定長分塊）低實時
流式訪問
5.1.2MapReduce模型115
》基本思想：拆任務合結果
》侷限性
1、只是一個計算模型，欠缺流程支持（有數據依賴）
2、任務觸發，不能持久服務，啓動和關閉和損耗
5.2Storm實時處理系統129
5.2.1歷史129
5.2.2計算模型130
》8種內置分組策略，作者簡單介紹了一下，我查閱資料整理如下
Shufflegrouping：隨機分組，Bolt均勻收到tuple
Fieldsgrouping：按字段分組，容易導致task不均衡
PartialKey grouping：按字段分組之後，在下游負載均衡，解決輸入不均衡
Allgrouping：全複製分給所有Bolt所有task，訂閱廣播
Globalgrouping：所有數據發給taskid最小的task，集中處理
Nonegrouping：相當於隨機分組，但會選擇訂閱bolt或spout在相同進程的bolt來執行，並未實現，也就是去下一步目的地執行。
Directgrouping：指向分組，定向指定
Localor shuffle grouping：相當於隨機分組，但會優先選擇本機處理，相當於哪裏發起哪裏執行
5.2.3總體架構133
》Nimbus節點：管理集羣
》每個計算節點一個Superviso負責與Nimbus通信，調度任務
》每個Superviso都有一個工作進程，進程內許多Executor
》新版每個Executor是一個獨立線程，執行一個任務Spout或Bolt
》Topolog（拓撲，作業描述）會在Nimbus的管理線，運行在整個集羣
》Topolog包含Spout（數據源）和Bolt（處理環節）
5.2.4Storm元數據133
》描述了storm本地存儲的數據，stom目錄下
5.2.5Storm與Hadoop比較138
5.3有保證的消息處理139
》Storm保證了消息被處理並且僅被是一次
》原理是元組數（TupleTree），賦與唯一ID
5.3.1完全處理與元組樹139
5.3.2元組的唯一標識139
5.3.3確認和失敗141
5.3.4高效實現143
》acket維護一個映射表，key是boltID，64位數，派生元組和ack成功時，分別異或一下，如果值是0，則表示全成功了，如果不成功，則是失敗的節點（一個時）的ID
5.4本章小結144
第6章實時處理系統編程接口設計145
》接口整體沒有什麼特色吧，分佈式的難點是於複雜的case的解決，並不是接口本身複雜。如果沒有分佈式基礎的，可以瞭解一下。
6.1總體架構設計145
》類storm系統
6.1.1Hurricane與Storm比較145
6.1.2總體架構146
6.1.3任務接口148
6.2消息源接口設計149
6.3消息處理器接口設計150
6.4數據收集器設計151
6.5元組接口設計154
6.6序列化接口設計160
6.7本章小結161
第7章服務組件設計與實現162
》基礎接口，跳過
7.1Executor設計與實現162
7.1.1事件驅動的消息隊列162
7.1.2動態裝載技術167
7.1.3Executor實現169
7.2Task設計與實現171
7.3本章小結172
第8章管理服務設計與實現173
》接口實現，跳過
8.1President功能與設計173
8.2President實現174
8.2.1簡單的網絡通信實現175
8.2.2Topology裝載實現182
8.2.3Manager管理調度實現184
8.2.4序列化實現193
8.3本章小結198
第9章實時處理系統編程接口實現199
》接口實現，跳過
9.1消息源接口實現200
9.1.1消息源執行器200
9.1.2WordCount實現實例205
9.2消息處理單元接口實現207
9.2.1消息處理單元執行器207
9.2.2事件處理212
9.2.3WordCount實現實例215
9.3數據收集器實現218
9.3.1分發策略218
9.3.2傳輸層實現224
9.4本章小結226
第10章可靠消息處理227
》基礎實現，跳過
10.1基本概念227
10.1.1完全處理227
10.1.2失敗與重發229
10.2接口設計229
10.3具體實現233
10.3.1簡單實現233
10.3.2高效實現235
10.4本章小結237
第11章通信系統設計與實現238
》基礎實現，跳過
11.1I/O多路複用方案解析239
11.1.1基本網絡編程接口239
11.1.2非阻塞的服務器程序241
11.1.3使用select()接口的基於事件驅動的服務器模型242
11.1.4使用epoll實現異步事件通知模型245
11.2基礎工具249
11.2.1線程工具250
11.2.2日誌工具254
11.3傳輸層實現263
11.3.1Reactor模式263
11.3.2定義抽象TP傳輸層264
11.3.3實現基於epoll的TP傳輸層269
11.3.4實現基於IOCP的TP傳輸層290
11.4應用層HTTP實現307
11.4.1HttpContext307
11.4.2HttpRequest311
11.4.3HttpResponse313
11.4.4HttpConnection315
11.4.5HttpServer317
11.4.6總結319
11.5跨平臺分割編譯320
11.5.1Makefile320
11.5.2Kake323
11.6與實時處理系統集成325
11.6.1修改NetListener325
11.6.2修改NetConnector327
11.7本章小結330
第12章事務性Topology實現331
12.1Exact-once語義解決方案331
》方案1
Topology存儲一個全局的唯一ID，生成遞增的元組ID。數據庫存儲元組數和當前ID。元組處理時訪問數據庫，如果ID不同，表示是新元組，更新ID並增加完成元組計數，否則是重複執行，忽略。
》方案2
同方案1相近，只是對元組分組，一次執行一組，一組越大，性能越好，但失敗時損失也越大
》方案3
梳理元組爲2部分，一部分是可並行的，一部分是順序執行的，並行部分併發，順序執行部分再嚴格控制順序。
12.2設計細節333
12.2.1構造事務性Topology333
12.2.2消息處理單元334
12.3事務性TopologyAPI337
12.3.1消息處理單元337
12.3.2事務性消息源339
12.4本章小結339
第13章多語言接口340
》基礎部分，跳過
13.1C語言通用接口340
13.1.1元組接口342
13.1.2消息源接口346
13.1.3消息處理單元接口349
13.1.4計算拓撲接口352
13.2Python接口354
13.2.1ctypes354
13.2.2元組接口356
13.2.3消息源接口359
13.2.4消息處理單元接口360
13.2.5計算拓撲接口361
13.2.6應用示例364
13.3JavaScript接口365
13.3.1V8引擎366
13.3.2Node.js366
13.3.3V8的互操作接口367
13.3.4任務接口368
13.3.5消息源接口369
13.3.6消息處理單元接口370
13.3.7計算拓撲接口371
13.3.8應用示例373
13.4Java接口375
13.4.1任務接口375
13.4.2消息源接口376
13.4.3消息處理單元接口377
13.4.4計算拓撲接口377
13.4.5本地代碼380
13.4.6應用示例382
13.5Swift接口384
13.5.1應用範圍385
13.5.2任務接口385
13.5.3消息源接口386
13.5.4消息處理單元接口387
13.5.5計算拓撲接口388
13.6本章小結390
第14章Squared設計與實現——實現高級抽象元語391
14.1StormTrident介紹391
》StormTrident是一個高併發低延遲的分佈式查詢（相當於分佈式sql）
14.1.1Squared示例391
14.1.2DRPC示例394
14.2Squared實現396
14.2.1SquaredTopology和Spout396
14.2.2SquaredBolt401
14.2.3Stream405
14.2.4狀態存儲410
14.2.5DRPC實現412
14.2.6操作與處理節點416
14.2.7流操作419
14.3本章小結423
第15章實戰：日誌流處理425
》簡單看看，跳過
15.1日誌流處理設計方案425
15.2實現Topology427
15.2.1編寫消息源427
15.2.2編寫索引消息處理單元428
15.2.3編寫統計消息處理單元429
15.3本章小結431
第16章實戰：頻繁組合查找432
》簡單看看，跳過
16.1背景介紹432
16.1.1數據挖掘概念432
16.1.2關聯規則和頻繁項集433
16.1.3啤酒與尿布435
16.2頻繁二項集挖掘方法435
16.2.1頻繁二項集435
16.2.2算法設計思路438
16.2.3Hurricane實現思路439
16.3編寫Spout439
16.4編寫Bolt441
16.4.1SplitBolt441
16.4.2PairCountBolt442
16.4.3PairTotalCountBolt443
16.4.4ConfidenceComputeBolt444
16.4.5SupportComputeBolt445
16.4.6FilterBolt447
16.5編寫Topology448
16.6本章小結449
第17章實戰：在AWS和阿里雲上部署Hurricane實時處理系統450
》由於作者是自己開發了一個分佈式系統，雲上的部署實際只是用了雲服務器，並非一般理解的雲服務架構好了分佈式，我們購買使用資源
17.1AWS部署450
17.1.1搭建虛擬私有云452
17.1.2配置安全組455
17.1.3加載EC2實例456
17.1.4彈性IP地址管理461
17.2阿里雲部署464
17.2.1創建虛擬私有云464
17.2.2管理安全組467
17.2.3創建ECS468
17.2.4SSH登錄471
17.3Hurricane分佈式部署與管理471
17.3.1分佈式部署原理472
17.3.2分佈式安裝配置472
17.3.3分佈式啓動476
17.4部署分佈式實時處理系統477
17.5未來之路478
17.6本章小結479