新書推薦：
《
汗青堂丛书147·光明时代：中世纪新史
》
售價：HK$
85.1
《
能成事的团队
》
售價：HK$
111.9
《
现代无人机鉴赏（珍藏版）
》
售價：HK$
78.2
《
汗青堂丛书·晚清风云（4册套装）：帝国的切口 清朝与中华传统文化 太平天国运动史 冲击与回应
》
售價：HK$
427.8
《
穿在身上的历史：世界服饰图鉴（增订珍藏版）
》
售價：HK$
557.8
《
历史的严妆：解读道学阴影下的南宋史学（中华学术·有道）
》
售價：HK$
109.8
《
海外中国研究·江南：中国文雅的源流
》
售價：HK$
76.2
《
迟缓的巨人：“大而不能倒”的反思与人性化转向
》
售價：HK$
77.3
|
| 編輯推薦： |
|
透过现象看本质，掌握高性能、高并发、实时系统设计与权衡之道
|
| 內容簡介： |
|
全书分为11章。第1章介绍了实时流计算技术的产生背景、使用场景和通用架构。第2章通过实时流计算数据的采集，详细分析了Java高性能编程的理论基础。第3-6章通过从头构造一个分布式实时流计算框架，详细剖析了实时流计算中的几个核心概念和技术重点，并通过多个开源流计算平台的实现来验证这些核心概念和技术重点。第7章谈论了当实在做不到“实时”时，我们应该作出的备选方案。第8-10章阐述了构建一个完整实时流计算系统时，必要的周边辅助系统。第11章给出实时流计算应用案例。
|
| 目錄：
|
前言
第1章 实时流计算 …… 1
1.1 大数据时代的新挑战：实时流计算 …… 1
1.2 实时流计算使用场景 …… 2
1.3 实时流数据的特点 …… 4
1.4 实时流计算系统架构 …… 6
1.4.1 数据采集 …… 6
1.4.2 数据传输 …… 7
1.4.3 数据处理 …… 8
1.4.4 数据存储 …… 8
1.4.5 数据展示 …… 9
1.5 本章小结 …… 10
第2章 数据采集 …… 11
2.1 设计数据采集的接口 …… 11
2.2 使用Spring Boot实现数据采集服务器 …… 12
2.3 BIO与NIO …… 14
2.3.1 BIO连接器 …… 14
2.3.2 NIO连接器 …… 17
2.4 NIO和异步 …… 19
2.4.1 CPU密集型任务 …… 19
2.4.2 IO密集型任务 …… 20
2.4.3 IO和CPU都密集型任务 …… 21
2.4.4 纤程 …… 22
2.4.5 Actor …… 24
2.4.6 NIO配合异步编程 …… 25
2.5 使用Netty实现数据采集服务器 …… 26
2.5.1 使用Netty实现数据采集API …… 27
2.5.2 异步编程 …… 29
2.5.3 流量控制和反向压力 …… 31
2.5.4 实现反向压力 …… 32
2.5.5 异步的不足之处 …… 36
2.6 本章小结 …… 36
第3章 实现单节点流计算应用 …… 38
3.1 自己动手写实时流计算框架 …… 38
3.1.1 用DAG描述流计算过程 …… 38
3.1.2 造一个流计算框架的轮子 …… 39
3.1.3 实现特征提取DAG节点 …… 42
3.1.4 实现特征提取DAG拓扑 …… 45
3.2 CompletableFuture方法与原理 …… 46
3.2.1 常用的CompletableFuture类方法 …… 47
3.2.2 CompletableFuture的工作原理 …… 49
3.3 采用CompletableFuture实现单节点流处理 …… 51
3.3.1 基于CompletableFuture实现流计算应用 …… 51
3.3.2 反向压力 …… 53
3.3.3 死锁 …… 54
3.3.4 再论流与异步的关系 …… 55
3.4 流计算应用的性能调优 …… 56
3.4.1 优化机制 …… 56
3.4.2 优化工具 …… 56
3.4.3 线程状态 …… 62
3.4.4 优化方向 …… 66
3.5 本章小结 …… 67
第4章 数据处理 …… 68
4.1 流计算到底在计算什么 …… 68
4.2 流数据操作 …… 70
4.2.1 过滤 …… 70
4.2.2 映射 …… 70
4.2.3 展开映射 …… 71
4.2.4 聚合 …… 72
4.2.5 关联 …… 73
4.2.6 分组 …… 75
4.2.7 遍历 …… 75
4.3 时间维度聚合特征计算 …… 76
4.4 关联图谱特征计算 …… 78
4.4.1 一度关联 …… 79
4.4.2 二度关联 …… 81
4.5 事件序列分析 …… 85
4.5.1 CEP编程模式 …… 86
4.5.2 Flink CEP实例 …… 87
4.6 模型学习和预测 …… 89
4.6.1 统计学习模型 …… 90
4.6.2 P-value检验 …… 90
4.6.3 机器学习模型 …… 91
4.7 本章小结 …… 93
第5章 实时流计算的状态管理 …… 94
5.1 流的状态 …… 94
5.1.1 流数据状态 …… 96
5.1.2 流信息状态 …… 97
5.2 采用Redis实现流信息状态管理 …… 98
5.2.1 时间维度聚合特征计算 …… 98
5.2.2 一度关联特征计算 …… 99
5.3 采用Apache Ignite实现流信息状态管理 …… 100
5.3.1 时间维度聚合分析 …… 101
5.3.2 一度关联特征计算 …… 103
5.4 扩展为集群 …… 105
5.4.1 基于Redis的状态集群 …… 106
5.4.2 局部性原理 …… 106
5.4.3 批次请求处理 …… 108
5.4.4 基于Apache Ignite的状态集群 …… 109
5.4.5 基于分布式文件系统的状态管理集群 …… 109
5.5 本章小结 …… 110
第6章 开源流计算框架 …… 111
6.1 Apache Storm …… 112
6.1.1 系统架构 …… 112
6.1.2 流的描述 …… 113
6.1.3 流的执行 …… 113
6.1.4 流的状态 …… 116
6.1.5 消息传达可靠性保证 …… 116
6.2 Spark Streaming …… 117
6.2.1 系统架构 …… 117
6.2.2 流的描述 …… 117
6.2.3 流的执行 …… 118
6.2.4 流的状态 …… 119
6.2.5 消息传达可靠性保证 …… 120
6.3 Apache Samza …… 120
6.3.1 系统架构 …… 120
6.3.2 流的描述 …… 121
6.3.3 流的执行 …… 123
6.3.4 流的状态 …… 126
6.3.5 消息传达可靠性保证 …… 126
6.4 Apache Flink …… 127
6.4.1 系统架构 …… 127
6.4.2 流的描述 …… 128
6.4.3 流的执行 …… 128
6.4.4 流的状态 …… 130
6.4.5 消息传达可靠性 …… 131
6.5 本章小结 …… 132
第7章 当做不到实时 …… 133
7.1 做不到实时的原因 …… 133
7.2 Lambda架构 …… 134
7.2.1 数据系统和Lambda架构思想 …… 135
7.2.2 Lambda架构 …… 135
7.2.3 Lambda架构在实时流计算中的运用 …… 137
7.3 Kappa架构与架构实例 …… 138
7.3.1 Kappa架构 …… 138
7.3.2 Kappa架构实例 …… 140
7.4 本章小结 …… 143
第8章 数据传输 …… 144
8.1 消息中间件 …… 144
8.1.1 为什么使用消息中间件 …… 145
8.1.2 消息中间件的工作模式 …… 146
8.1.3 消息模式 …… 147
8.1.4 使用消息中间件的注意事项 …… 149
8.2 Apache Kafka …… 150
8.2.1 Kafka架构 …… 150
8.2.2 Kafka生产者
|
| 內容試閱：
|
为什么要写这本书
大概但凡写文章，都应该是在夜深人静的时候吧。
回顾来沪四年，思绪一下子回到了到沪的第一天。那是我第一次来上海。虽然没有小马哥勇闯上海滩的豪情万丈，但似乎也并未十分惆怅。拖着行李箱去新公司报到，当时住的地方尚未找好，新公司的名字竟也还未确定。报到的新公司，真的是一家“新”公司，刚刚成立不久，办公室在一个略显陈旧的大楼内，后来才知道那个办公室内还有另外一个公司的人员在那儿办公。当时辉哥接待了我，交给我一个Mac电脑，给我讲了一下公司的业务和系统现状。那是我第一次使用Mac电脑，操作还十分生疏。而现在，我正用着这台电脑，写着这篇自序（前言）。后来海阳到了，他给我展示和讲解了公司当时的产品。再后来，他还教了我怎样用Mac电脑。下午的时候我提前下班，拖着行李箱找住的地方去了。那天，当忙完一切躺到床上时，我意识到一切真的都是新的开始了。新的城市、新的公司、新的同事、新的业务、新的领域和新的工作内容。
之后就是正式的工作了。
因为是做Java开发的，所以花一天半时间学了Django，之后接手了Python后台开发。
因为是做Java开发的，所以花一天时间装了Android Studio，开始了SDK与后台的适配。
因为是做Java开发的，所以Java后台服务更是当仁不让了。
因为是做Java开发的，所以也要负责业务核心算法的开发。
因为是做Java开发的，所以DevOps也得负责推进吧。
因为是做Java开发的，所以……
那应该是我最专心地做开发的一段时间，甚至在一年之后的公司年会上，我还因此获得了一个“最佳沉默奖”。其实并非我不说话，而是每次市场部的同事看到我时，我都是在座位上写程序，好像我从来没离开过座位一样。是的，我一直在开发着，但是并不感到忙碌和紧迫，因为有充足的时间去思考问题、验证猜想并最终解决问题。
从2015年开始，公司因为业务需要，开始涉及实时流计算领域。当时流计算技术远非像现在这样普及，Flink还没有在国内流行起来，Spark Streaming处于“半吊子”状态，Storm则还是简单的TopologyBuilder。不过最主要的问题还是，虽然当时公司意识到要使用实时流计算技术，但没有人真正理解实时流计算系统到底该怎么用，应该怎样将流计算真正贴切地运用到我们的业务需求中。
在这种情况下，作为后台开发的我开始了自己的思考和探索。其实解决问题的思路非常简单，用最自然、最贴切、最实际、最节省资源的方式去解决真实的业务问题。最开始，我们选择Akka来作为流计算框架，但是因为对Akka的特性理解不到位，后来开发出的程序出现各种问题。例如，在Actor中光明正大地休眠（sleep）、对反向压力不管不顾，结果程序总是时不时宕掉、错误使用Akka Cluster导致集群脑裂等。
在程序开发过程中，我是一个谨小慎微的人，对于任何不确定性的因素，只要想到了就一定会尽力去避免，即使当时其他人不甚理解。所以从一开始，我就在自己负责的模块中，对Akka添加了反向压力的支持，就是为了避免执行步调不一致时导致的OOM。从后来的结果看，当时的做法是非常正确的。虽然在Akka中添加了反向压力的支持，但回看起来，实现得过于复杂。虽然保证了反向压力带来的程序稳定性，可是在50行的代码中，只有1行代码是涉及业务处理的。这种解决方案显然非常不明智。
当时，我还在极力尝试尽可能提高程序的性能，希望充分“榨干”机器的CPU和IO资源，以尽可能降低硬件成本。经过一段时间的调研和思考，我逐渐发现，NIO和异步才是彻底“榨干”CPU与IO资源的关键所在。虽然纤程（或协程）也是一种充分利用资源的完美手段，但可惜当时JVM领域尚无一个公开好用的完美纤程实现方案。
那时候，我开始隐隐约约地意识到，似乎“流”是一种非常好的编程模式。
首先，“流”与“异步”不谋而合。“流”的各个节点通过队列传递消息，不同节点的执行正好就是完全异步的。另外，由于队列隔离，不同节点的执行完全不用考虑并发安全的问题。
其次，如果“流”的执行节点间使用的是阻塞队列，那么整个流的各个执行环节就天然地带有了反向压力能力，不需要像之前在Akka中那样非常复杂的实现。
再次，“流”能够非常自然地描述业务执行的流程。不管是大到整个产品线的各个服务模块，还是小到每个服务模块中的具体实现步骤，就像“分形”一样，“流”能够做任意细粒度的划分。这是一种非常普遍的描述事情发生过程的模式。
最后，通过Kafka这种消息中间件的隔离，我可以非常清晰地定义好自己负责开发模块的责任边界，与其他同事的程序隔离开来，避免纠缠不清。当然，这是一种自私的想法，但是从设计模式高内聚、低耦合的角度来看，这又何尝不是一种非常不错的实践呢？更何况Kafka这种好用到“爆”的消息队列，真的是让人爱不释手！
于是，说干就干，我花了一个周末的时间，编写了第一个版本的流计算框架。之后又经过几次大大小小的调整和改进，最终，这个流计算框架进入了公司所有产品的主要业务模块中。再后来，我又在这个流计算框架上开发了一个特征引擎，支持DSL和脚本，可以非常灵活、方便、快速地在流数据上即写即算地实现各种特征计算。所有特征计算都是并发
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
