【分享说明】：
我会花很多时间或浅或深的研读一本书，然后总结一些提炼出来的精华，用简短的语言，让其他人能够用很少的时间大致知道这本书能带给自己的价值，如果适用自己，鼓励买一本正本实体书细读和收藏。
通篇会以原文目录为结构，给出提炼内容，如果不重要或者一看目录就懂的，会保留目录，有不明白的，以原文学习为参照。
所有分享内容，为了区分，会以》开头，可能有多行缩进，或差异化颜色表示。
【书名】：《分布式实时处理系统 原理、架构与实现》
【作者】：卢誉声，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
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
