[套装书]分布式系统架构：技术栈详解与快速进阶+大规模分布式存储系统：原理解析与架构实战（2册）

.

---------------------------大规模分布式存储系统：原理解析与架构实战---------------------------


《大规模分布式存储系统：原理解析与架构实战》是分布式系统领域的经典著作，由阿里巴巴高级技术专家“阿里日照”（OceanBase核心开发人员）撰写，阳振坤、章文嵩、杨卫华、汪源、余锋（褚霸）、赖春波等来自阿里、新浪、网易和百度的资深技术专家联袂推荐。理论方面，不仅讲解了大规模分布式存储系统的核心技术和基本原理，而且对谷歌、亚马逊、微软和阿里巴巴等国际型大互联网公司的大规模分布式存储系统进行了分析；实战方面，首先通过对阿里巴巴的分布式数据库OceanBase的实现细节的深入剖析完整地展示了大规模分布式存储系统的架构与设计过程，然后讲解了大规模分布式存储技术在云计算和大数据领域的实践与应用。

《大规模分布式存储系统：原理解析与架构实战》内容分为四个部分：基础篇——分布式存储系统的基础知识，包含单机存储系统的知识，如数据模型、事务与并发控制、故障恢复、存储引擎、压缩/解压缩等；分布式系统的数据分布、复制、一致性、容错、可扩展性等。范型篇——介绍谷歌、亚马逊、微软、阿里巴巴等著名互联网公司的大规模分布式存储系统架构，涉及分布式文件系统、分布式键值系统、分布式表格系统以及分布式数据库技术等。实践篇——以阿里巴巴的分布式数据库OceanBase为例，详细介绍分布式数据库内部实现，以及实践过程中的经验。专题篇——介绍分布式系统的主要应用：云存储和大数据，这些是近年来的热门领域，本书介绍了云存储平台、技术与安全，以及大数据的概念、流式计算、实时分析等。

2.1　前后端交互发展过程 15
2.1.1　传统交互模式 16
2.1.2　前后端分离交互模式 19
2.1.3　整体交互 22
2.2　前后端交互方式 22
2.2.1　工作流程 22
2.2.2　交互常见状态码 29
2.3　前后端交互难点 30
2.4　前后端交互优化 32
2.5　案例讲解 37
2.6　本章小结 40
第3章　分布式架构网络传输 41
3.1　网络传输协议 41
3.2　网络传输调用过程 46
3.2.1　协议概述 46
3.2.2　传输过程 48
3.3　网络传输优化 52
3.4　本章小结 54
第4章　分布式架构Nginx 55
4.1　Nginx工作原理 55
4.2　Nginx源码编译安装 57
4.3　Nginx配置 62
4.4　Nginx代理&负载均衡 64
4.4.1　正向代理 66
4.4.2　反向代理 66
4.4.3　动静分离 68
4.4.4　负载均衡策略 69
4.5　Nginx缓存 74
4.6　Nginx限流 76
4.7　Nginx屏蔽 79
4.8　Nginx优化 79
4.8.1　优化思路 79
4.8.2　核心配置优化 79
4.9　Nginx高可用 82
4.10　本章小结 86
第5章　分布式架构Varnish 87
5.1　Varnish工作原理 87
5.2　Varnish源码编译安装 89
5.3　Varnish配置 92
5.4　Varnish核心指令 98
5.4.1　Varnish核心指令之backend 98
5.4.2　Varnish核心指令之director 98
5.5　Varnish缓存 102
5.5.1　Varnish缓存状态 102
5.5.2　Varnish缓存管理 104
5.6　Varnish处理策略 105
5.6.1　pass 106
5.6.2　pipe 106
5.6.3　lookup 107
5.7　Varnish健康检查 107
5.8　Varnish优化 109
5.8.1　Varnish优化思路 109
5.8.2　Varnish优化讲解 109
5.9　Varnish高可用 111
5.10　本章小结 116
第6章　分布式架构Tomcat 117
6.1　Tomcat原理 117
6.2　Tomcat生命周期 123
6.3　Tomcat源码编译安装 124
6.4　Tomcat目录结构 126
6.4.1　bin目录 126
6.4.2　conf目录 127
6.4.3　lib目录 128
6.4.4　logs目录 129
6.4.5　webapps目录 129
6.5　Tomcat加载过程 130
6.5.1　Bootstrap类初始化 130
6.5.2　Bootstrap启动 132
6.6　Tomcat安全 135
6.6.1　配置调整 135
6.6.2　安全策略 136
6.6.3　SSL传输安全 136
6.7　Tomcat集群 137
6.7.1　集群组件实现 138
6.7.2　集群配置 139
6.8　JVM 142
6.8.1　Class文件结构 143
6.8.2　类的装载、连接和初始化 145
6.8.3　JVM的内存分配 148
6.8.4　JVM执行引擎 151
6.8.5　垃圾回收 152
6.9　Tomcat性能调优 158
6.9.1　性能测试 158
6.9.2　性能优化 162
6.10　本章小结 167
第7章　分布式架构高并发 168
7.1　高并发使用场景 169
7.2　高并发难点 171
7.2.1　高并发期间如何避免产生脏数据 171
7.2.2　当出现脏数据后如何处理 171
7.2.3　高并发期间如何节约带宽 172
7.3　高并发之缓存 174
7.3.1　Redis介绍 174
7.3.2　Redis原理 175
7.3.3　Redis安装编译 176
7.3.4　Redis数据结构 178
7.3.5　Redis持久化 181
7.3.6　Redis事务 183
7.3.7　Redis分布式锁 186
7.3.8　Redis任务队列 189
7.3.9　Redis高并发处理常见问题及解决方案 201
7.3.10　Redis高可用 211
7.3.11　Redis调优 213
7.4　高并发之消息队列 214
7.4.1　RocketMQ介绍 214
7.4.2　RocketMQ安装编译 217
7.4.3　RocketMQ应用场景 221
7.4.4　RocketMQ路由中心 222
7.4.5　RocketMQ消息存储结构 224
7.4.6　RocketMQ刷盘和复制策略 226
7.4.7　RocketMQ消息队列 227
7.4.8　RocketMQ高并发处理常见问题及解决方案 238
7.4.9　RocketMQ集群 240
7.4.10　RocketMQ调优 240
7.5　高并发优化 242
7.5.1　优化思路 242
7.5.2　优化方案 243
7.6　高并发经典案例 245
7.7　本章小结 249
第8章　分布式架构事务 250
8.1　分布式事务介绍 251
8.1.1　本地事务 251
8.1.2　全局事务 253
8.1.3　两阶段提交 254
8.1.4　分布式事务 255
8.1.5　小结 255
8.2　分布式事务概论 256
8.2.1　CAP定理 256
8.2.2　BASE理论 257
8.3　分布式事务应用场景 258
8.4　分布式事务难点 259
8.4.1　网络因素 259
8.4.2　消息重复发送 260
8.4.3　CAP定理选择 262
8.5　分布式事务解决方案 262
8.5.1　最大努力通知 263
8.5.2　TCC事务补偿 273
8.5.3　消息一致性 284
8.6　分布式事务案例讲解 295
8.7　本章小结 297
第9章　分布式架构MySQL 298
9.1　MySQL运行原理 299
9.2　MySQL编译启动 304
9.3　MySQL事务 307
9.3.1　事务特性 307
9.3.2　隔离级别 308
9.3.3　死锁 308
9.3.4　事务日志 309
9.4　MySQL存储引擎 310
9.4.1　概述 310
9.4.2　InnoDB 311
9.4.3　MyISAM 313
9.5　MySQL之SQL操作 314
9.5.1　SQL介绍 314
9.5.2　库 316
9.5.3　表 316
9.6　MySQL索引 317
9.6.1　索引概述 317
9.6.2　数据结构 318
9.6.3　索引分类 319
9.6.4　创建索引 319
9.7　MySQL备份 321
9.7.1　备份概述 321
9.7.2　备份类型 321
9.7.3　备份内容 322
9.8　MySQL难点 323
9.8.1　死锁 323
9.8.2　连接数过多 325
9.8.3　主从复制延迟 325
9.8.4　CPU飙高 326
9.8.5　索引效率 326
9.9　MySQL性能优化 326
9.9.1　优化思路 326
9.9.2　优化过程 327
9.10　MySQL集群 331
9.11　本章小结 333
第10章　分布式架构高可用 334
10.1　高可用概述及难点 334
10.2　高可用涉及内容 336
10.3　高可用具体应用 344
10.4　高可用案例讲解 345
10.5　本章小结 346



---------------------------大规模分布式存储系统：原理解析与架构实战---------------------------


《大规模分布式存储系统：原理解析与架构实战》
前言
第1章　概述 /1
1.1　分布式存储概念 /1
1.2　分布式存储分类 /2
第一篇　基础篇
第2章　单机存储系统 /6
2.1　硬件基础 /6
2.1.1　CPU架构 /6
2.1.2　IO总线 /7
2.1.3　网络拓扑 /9
2.1.4　性能参数 /10
2.1.5　存储层次架构 /11
2.2　单机存储引擎 /12
2.2.1　哈希存储引擎 /12
2.2.2　B树存储引擎 /14
2.2.3　LSM树存储引擎 /15
2.3　数据模型 /17
2.3.1　文件模型 /17
2.3.2　关系模型 /18
2.3.3　键值模型 /19
2.3.4　SQL与NoSQL /20
2.4　事务与并发控制 /21
2.4.1　事务 /21
2.4.2　并发控制 /23
2.5　故障恢复 /26
2.5.1　操作日志 /26
2.5.2　重做日志 /27
2.5.3　优化手段 /27
2.6　数据压缩 /29
2.6.1　压缩算法 /29
2.6.2　列式存储 /33
第3章　分布式系统 /36
3.1　基本概念 /36
3.1.1　异常 /36
3.1.2　一致性 /38
3.1.3　衡量指标 /39
3.2　性能分析 /40
3.3　数据分布 /42
3.3.1　哈希分布 /43
3.3.2　顺序分布 /45
3.3.3　负载均衡 /46
3.4　复制 /47
3.4.1　复制的概述 /47
3.4.2　一致性与可用性 /49
3.5　容错 /50
3.5.1　常见故障 /50
3.5.2　故障检测 /51
3.5.3　故障恢复 /52
3.6　可扩展性 /53
3.6.1　总控节点 /54
3.6.2　数据库扩容 /54
3.6.3　异构系统 /56
3.7　分布式协议 /57
3.7.1　两阶段提交协议 /57
3.7.2　Paxos协议 /59
3.7.3　Paxos与2PC /60
3.8　跨机房部署 /60
第二篇　范型篇
第4章　分布式文件系统 /66
4.1　Google文件系统 /66
4.1.1　系统架构 /66
4.1.2　关键问题 /67
4.1.3　Master设计 /72
4.1.4　ChunkServer设计 /74
4.1.5　讨论 /74
4.2　Taobao File System /75
4.2.1　系统架构 /75
4.2.2　讨论 /78
4.3　Facebook Haystack /78
4.3.1　系统架构 /79
4.3.2　讨论 /82
4.4　内容分发网络 /83
4.4.1　CDN架构 /83
4.4.2　讨论 /85
第5章　分布式键值系统 /86
5.1　Amazon Dynamo /86
5.1.1　数据分布 /86
5.1.2　一致性与复制 /88
5.1.3　容错 /89
5.1.4　负载均衡 /90
5.1.5　读写流程 /91
5.1.6　单机实现 /92
5.1.7　讨论 /93
5.2　淘宝Tair /93
5.2.1　系统架构 /93
5.2.2　关键问题 /94
5.2.3　讨论 /96
第6章　分布式表格系统 /97
6.1　Google Bigtable /97
6.1.1　架构 /98
6.1.2　数据分布 /100
6.1.3　复制与一致性 /101
6.1.4　容错 /101
6.1.5　负载均衡 /102
6.1.6　分裂与合并 /102
6.1.7　单机存储 /103
6.1.8　垃圾回收 /104
6.1.9　讨论 /105
6.2　Google Megastore /105
6.2.1　系统架构 /107
6.2.2　实体组 /108
6.2.3　并发控制 /109
6.2.4　复制 /110
6.2.5　索引 /111
6.2.6　协调者 /111
6.2.7　读取流程 /112
6.2.8　写入流程 /113
6.2.9　讨论 /115
6.3　Windows Azure Storage /115
6.3.1　整体架构 /115
6.3.2　文件流层 /117
6.3.3　分区层 /121
6.3.4　讨论 /125
第7章　分布式数据库 /126
7.1　数据库中间层 /126
7.1.1　架构 /126
7.1.2　扩容 /128
7.1.3　讨论 /128
7.2　Microsoft SQL Azure /129
7.2.1　数据模型 /129
7.2.2　架构 /131
7.2.3　复制与一致性 /132
7.2.4　容错 /132
7.2.5　负载均衡 /133
7.2.6　多租户 /133
7.2.7　讨论 /134
7.3　Google Spanner /134
7.3.1　数据模型 /134
7.3.2　架构 /135
7.3.3　复制与一致性 /136
7.3.4　TrueTime /137
7.3.5　并发控制 /138
7.3.6　数据迁移 /139
7.3.7　讨论 /139
第三篇　实践篇
第8章　OceanBase架构初探 /142
8.1　背景简介 /142
8.2　设计思路 /143
8.3　系统架构 /144
8.3.1　整体架构图 /144
8.3.2　客户端 /145
8.3.3　RootServer /147
8.3.4　MergeServer /148
8.3.5　ChunkServer /149
8.3.6　UpdateServer /149
8.3.7　定期合并&数据分发 /150
8.4　架构剖析 /151
8.4.1　一致性选择 /151
8.4.2　数据结构 /152
8.4.3　可靠性与可用性 /154
8.4.4　读写事务 /154
8.4.5　单点性能 /155
8.4.6　SSD支持 /156
8.4.7　数据正确性 /157
8.4.8　分层结构 /158
第9章　分布式存储引擎 /159
9.1　公共模块 /159
9.1.1　内存管理 /159
9.1.2　基础数据结构 /161
9.1.3　锁 /164
9.1.4　任务队列 /165
9.1.5　网络框架 /166
9.1.6　压缩与解压缩 /167
9.2　RootServer实现机制 /168
9.2.1　数据结构 /168
9.2.2　子表复制与负载均衡 /170
9.2.3　子表分裂与合并 /171
9.2.4　UpdateServer选主 /172
9.2.5　RootServer主备 /173
9.3　UpdateServer实现机制 /174
9.3.1　存储引擎 /174
9.3.2　任务模型 /179
9.3.3　主备同步 /181
9.4　ChunkServer实现机制 /183
9.4.1　子表管理 /183
9.4.2　SSTable /184
9.4.3　缓存实现 /188
9.4.4　IO实现 /190
9.4.5　定期合并&数据分发 /191
9.4.6　定期合并限速 /192
9.5　消除更新瓶颈 /193
9.5.1　读写优化回顾 /193
9.5.2　数据旁路导入 /195
9.5.3　数据分区 /195
第10章　数据库功能 /197
10.1　整体结构 /197
10.2　只读事务 /199
10.2.1　物理操作符接口 /201
10.2.2　单表操作 /202
10.2.3　多表操作 /203
10.2.4　SQL执行本地化 /205
10.3　写事务 /206
10.3.1　写事务执行流程 /206
10.3.2　多版本并发控制 /208
10.4　OLAP业务支持 /212
10.4.1　并发查询 /212
10.4.2　列式存储 /214
10.5　特色功能 /215
10.5.1　大表左连接 /215
10.5.2　数据过期与批量删除 /216
第11章　质量保证、运维及实践 /218
11.1　质量保证 /218
11.1.1　RD开发 /219
11.1.2　QA测试 /222
11.1.3　试运行 /224
11.2　使用与运维 /225
11.2.1　使用 /225
11.2.2　运维 /227
11.3　应用 /228
11.3.1　收藏夹 /229
11.3.2　天猫评价 /230
11.3.3　直通车报表 /231
11.4　最佳实践 /232
11.4.1　系统发展路径 /232
11.4.2　人员成长 /234
11.4.3　系统设计 /236
11.4.4　系统实现 /237
11.4.5　使用与运维 /238
11.4.6　工程现象 /239
11.4.7　经验法则 /240
第四篇　专题篇
第12章　云存储 /242
12.1　云存储的概念 /242
12.2　云存储的产品形态 /245
12.3　云存储技术 /247
12.4　云存储的核心优势 /249
12.5　云平台整体架构 /251
12.5.1　Amazon云平台 /252
12.5.2　Google云平台 /253
12.5.3　Microsoft云平台 /255
12.5.4　云平台架构 /258
12.6　云存储技术体系 /261
12.7　云存储安全 /263
第13章　大数据 /267
13.1　大数据的概念 /267
13.2　MapReduce /269
13.3　MapReduce扩展 /270
13.3.1　Google Tenzing /271
13.3.2　Microsoft Dryad /274
13.3.3　Google Pregel /275
13.4　流式计算 /276
13.4.1　原理 /276
13.4.2　Yahoo S4 /278
13.4.3　Twitter Storm /279
13.5　实时分析 /281
13.5.1　MPP架构 /281
13.5.2　EMC Greenplum /282
13.5.3　HP Vertica /285
13.5.4　Google Dremel /286
参考资料 /288

.　　第3章主要介绍分布式环境中网络传输的过程、难点、性能调优。
　　第4章主要介绍Nginx的负载均衡、页面缓存、限流、高可用、性能调优。
　　第5章主要介绍Varnish的HTTP加速、缓存策略、高可用、性能调优。
　　第6章主要介绍Tomcat的原理、加载机制、安全管理、高可用集群、性能调优。
　　第7章主要介绍分布式环境中高并发的问题，通过多种技术方案，如缓存、消息队列、分布式锁等去优化处理，以提高系统整体的吞吐量。
　　第8章主要介绍普通事务与分布式事务的差异性，以及对分布式事务的多种处理方式，本章会通过多个案例并结合代码进行分析。
　　第9章主要介绍MySQL数据库的特性，即如何通过高效索引优化、高可用的技术方案让MySQL提供更高效的数据库服务。
　　第10章主要介绍分布式环境中高可用的相关内容，即如何通过容量预估、全链路压测、容灾设计来提高系统整体的可用性和健壮性。
　　勘误
　　由于水平有限，加之编写时间仓促，本书中可能会出现一些错误和表述不准确的地方，希望读者朋友批评指正。大家可以通过CSDN博客专栏（https://blog.csdn.net/qaz7225277/category_9290006.html）留言反馈，期待得到你们的反馈和建议。
　　致谢
　　首先要感谢《RocketMQ技术内幕》的作者丁威对我的指导，为我的职业发展提供的诸多帮助。
　　感谢分布式领域与我探讨技术的朋友们，他们是姜伟、丁威、张登、沈尚伟、张瑾、孙凯、武万祥、黄正云、万振崎、张磊、谢书愉、王义武以及线下交流过的每位朋友，感谢他们对我的支持和帮助。感谢张瑾的引荐，感谢范文嵩的指点，感谢名锋的分享，是他们的努力和付出为我指明了前进的方向。
　　感谢机械工业出版社华章公司的杨福川老师，他在这一年多的时间中支持我的写作，并与我分享写书的经验。他的支持和鼓励让我坚持写作。感谢机械工业出版社华章公司的李艺老师、李杨老师，她们在我写作这一年多的时间中提供了诸多帮助，引导我顺利完成全部书稿。
　　最后感谢我的爸爸、妈妈、外婆将我培养成人，给予我莫大的关心和支持。感谢我的妻子、儿子，他们是我前进的最大动力。
　　
　　
　　---------------------------大规模分布式存储系统：原理解析与架构实战---------------------------
　　
　　
　　随着社交网络、移动互联网、电子商务等技术的不断发展，互联网的使用者贡献了越来越多的内容。为了处理这些内容，每个互联网公司在后端都有一套成熟的分布式系统用于数据的存储、计算以及价值提取。Google是全球最大的互联网公司，也是在分布式技术上相对成熟的公司，其公布的Google分布式文件系统GFS、分布式计算系统MapReduce、分布式表格系统Bigtable都成为业界竞相模仿的对象，最近公布的全球数据库Spanner更是能够支持分布在世界各地上百个数据中心的上百万台服务器。Google的核心技术正是后端这些处理海量数据的分布式系统。和Google类似，国外的亚马逊、微软以及国内互联网三巨头阿里巴巴、百度和腾讯的核心技术也是其后端的海量数据处理系统。
　　本书的内容是介绍互联网公司的大规模分布式存储系统。与传统的高端服务器、高端存储器和高端处理器不同的是，互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通PC服务器通过网络连接而成。互联网的业务发展很快，而且注重成本，这就使得存储系统不能依靠传统的纵向扩展的方式，即先买小型机，不够时再买中型机，甚至大型机。互联网后端的分布式系统要求支持横向扩展，即通过增加普通PC服务器来提高系统的整体处理能力。普通PC服务器性价比高，故障率也高，需要在软件层面实现自动容错，保证数据的一致性。另外，随着服务器的不断加入，需要能够在软件层面实现自动负载均衡，使得系统的处理能力得到线性扩展。
　　分布式存储和当今同样备受关注的云存储和大数据又是什么关系呢？分布式存储是基础，云存储和大数据是构建在分布式存储之上的应用。移动终端的计算能力和存储空间有限，而且有在多个设备之间共享资源的强烈的需求，这就使得网盘、相册等云存储应用很快流行起来。然而，万变不离其宗，云存储的核心还是后端的大规模分布式存储系统。大数据则更近一步，不仅需要存储海量数据，还需要通过合适的计算框架或者工具对这些数据进行分析，抽取其中有价值的部分。如果没有分布式存储，便谈不上对大数据进行分析。仔细分析还会发现，分布式存储技术是互联网后端架构的“九阳神功”，掌握了这项技能，以后理解其他技术的本质会变得非常容易。
　　分布式存储技术如此重要，市面上也有很多分布式系统相关的书籍。然而，这些书籍往往注重理论不重实践，且所述理论也不太适合互联网公司的大规模存储系统。这是因为，虽然分布式系统研究了很多年，但是大规模分布式存储系统是在近几年才流行起来，而且起源于以Google为首的企业界而非学术界。笔者2007年年底加入百度公司，师从阳振坤老师，从事大规模分布式存储的研究和实践工作，曾经开发过类似GFS、MapReduce和Bigtable的分布式系统，后来转战阿里巴巴继续开发分布式数据库OceanBase，维护分布式技术博客NosqlNotes（http://www.nosqlnotes.net）。笔者在业余时间阅读并理解了绝大部分分布式系统原理和各大互联网公司的系统范型相关论文，深知分布式存储系统的复杂性，也能够体会到广大读者渴望弄清楚分布式存储技术本质和实现细节的迫切心情，因而集中精力编写了这本书，希望对从事分布式存储应用的技术人员有所裨益。
　　本书的目标是介绍互联网公司的大规模分布式存储系统，共分为四篇：
　　基础篇。基础知识包含两个部分：单机存储系统以及分布式系统。其中，单机存储系统的理论基础是数据库技术，包括数据模型、事务与并发控制、故障恢复、存储引擎、数据压缩等；分布式系统涉及数据分布、复制、一致性、容错、可扩展性等分布式技术。另外，分布式存储系统工程师还需要一项基础训练，即性能预估，因此，基础篇也会顺带介绍硬件基础知识以及性能预估方法。
　　范型篇。这部分内容将介绍Google、亚马逊、微软、阿里巴巴等各大互联网公司的大规模分布式存储系统，分为四章：分布式文件系统、分布式键值系统、分布式表格系统以及分布式数据库。
　　实践篇。这部分内容将以笔者在阿里巴巴开发的分布式数据库OceanBase为例详细介绍分布式数据库内部实现以及实践过程中的经验总结。
　　专题篇。云存储和大数据是近年来兴起的两大热门领域，其底层都依赖分布式存储技术，这部分将简单介绍这两方面的基础知识。
　　本书适合互联网行业或者其他从事分布式系统实践的工程人员，也适合大学高年级本科生和研究生作为分布式系统或者云计算相关课程的参考书籍。阅读本书之前，建议首先理解分布式系统和数据库相关基础理论，接着阅读第一篇。如果对各个互联网公司的系统架构感兴趣，可以选择阅读第二篇的某些章节；如果对阿里巴巴OceanBase的架构设计和实现感兴趣，可以顺序阅读第三篇。最后，如果对云存储或者大数据感兴趣，可以选择阅读第四篇的某个章节。
　　感谢阳振坤老师多年以来对我在云计算和分布式数据库这两个领域的研究实践工作的指导和鼓励。感谢在百度以及阿里巴巴与我共事多年的兄弟姐妹，我们患难与共，一起实现共同的梦想。感谢机械工业出版社的吴怡编辑、新浪微博的杨卫华先生、百度的侯震宇先生以及支付宝的童家旺先生在本书撰写过程中提出的宝贵意见。
　　由于分布式存储技术涉及一些公司的商业机密，加上笔者水平有限、时间较紧，所以书中难免存在谬误，很多技术点涉及的细节描述得还不够详尽，恳请读者批评指正。可将任何意见和建议发送到我的邮箱knuthocean@163.com，本书相关的勘误和技术细节说明也会发布到我的个人博客NosqlNotes。我的新浪微博账号是“阿里日照”，欢迎读者通过邮件、博客或者微博与我交流分布式存储相关的任何问题。我也将密切跟踪分布式存储技术的发展，吸收您的意见，适时编写本书的升级版本。
　　杨传辉
　　2013年7月于北京
　　

.　　
　　分布式存储系统是分布式系统中最基础、最复杂的部分，它涉及数据的持久化、一致性和可用性，针对不同的访问需求在架构上有很多不同的取舍。本书作者在分布式存储系统方面有多年的实践经验，将所见所思所得凝聚成这本书，其中涵盖很多典型的分布式存储系统，是了解分布式系统的很好读物。
　　—— 章文嵩，阿里巴巴高级研究员，核心系统部负责人，LVS作者
　　本书覆盖的信息量及知识点非常全面，是了解分布式存储不可多得的书籍，对指导分布式领域开发也具有重要参考价值。
　　—— 杨卫华，新浪微博首席架构师
　　分布式存储这个领域面宽水深，无论是分布式理论、存储还是案例，铺开写都是卷帙浩繁。本书一是胜在围绕最具广泛实用价值的基于通用硬件构建大规模分布式存储系统这一核心进行了很好的材料组织选取；二是胜在对OceanBase实现机制的深度剖析。本书作者是OceanBase的核心开发人员，对分布式存储系统身体力行，自然有很多独特的洞见。因此，本书实用性和独特性俱佳，必须入手一读。
　　—— 汪源，网易杭州研究院副院长
　　分布式系统固有的复杂性加上大规模存储系统的工程挑战，让真正理解这个体系变得非常困难。作者在相关领域拥有多年一线开发经验，从实践工作中将相关知识萃取出来，清晰地呈现给读者。因此，我愿意将此书推荐给真正想了解分布式存储系统原理并勇于实践的读者。
　　—— 余锋，阿里巴巴资深技术专家，花名褚霸，有知名博客：http://blog.yufeng.info/
　　作者先后在百度、阿里巴巴等公司长期致力于大规模存储和分布式等技术的研究，对BigTable、Dynamo等业界知名存储系统也有深入的了解，同时在Pyramid、OceanBase等系统的架构、设计和开发上有过大量的实践工作。大规模存储是互联网和云计算产业的基石，而作者的这些技术是能真正应用在工业系统中的。难能可贵的是，作者将这些技术细节和系统如此有条理地展现出来，无论对大规模存储和分布式领域的初学者还是进阶者，都有巨大的帮助。
　　—— 赖春波，百度架构师，分布式存储技术负责人
　　

.　　容错：如何检测到服务器故障？如何自动将出现故障的服务器上的数据和服务迁移到集群中其他服务器？
　　负载均衡：新增服务器和集群正常运行过程中如何实现自动负载均衡？数据迁移的过程中如何保证不影响已有服务？
　　事务与并发控制：如何实现分布式事务？如何实现多版本并发控制？
　　易用性：如何设计对外接口使得系统容易使用？如何设计监控系统并将系统的内部状态以方便的形式暴露给运维人员？
　　压缩/解压缩：如何根据数据的特点设计合理的压缩/解压缩算法？如何平衡压缩算法节省的存储空间和消耗的CPU计算资源？
　　分布式存储系统挑战大，研发周期长，涉及的知识面广。一般来讲，工程师如果能够深入理解分布式存储系统，理解其他互联网后台架构不会再有任何困难。
　　1.2分布式存储分类
　　分布式存储面临的数据需求比较复杂，大致可以分为三类：
　　非结构化数据：包括所有格式的办公文档、文本、图片、图像、音频和视频信息等。
　　结构化数据：一般存储在关系数据库中，可以用二维关系表结构来表示。结构化数据的模式（Schema，包括属性、数据类型以及数据之间的联系）和内容是分开的，数据的模式需要预先定义。
　　半结构化数据：介于非结构化数据和结构化数据之间，HTML文档就属于半结构化数据。它一般是自描述的，与结构化数据最大的区别在于，半结构化数据的模式结构和内容混在一起，没有明显的区分，也不需要预先定义数据的模式结构。
　　不同的分布式存储系统适合处理不同类型的数据，本书将分布式存储系统分为四类：分布式文件系统、分布式键值（Key-Value）系统、分布式表格系统和分布式数据库。
　　1．分布式文件系统
　　互联网应用需要存储大量的图片、照片、视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob（Binary Large Object，二进制大对象）数据。
　　分布式文件系统用于存储Blob对象，典型的系统有Facebook Haystack以及Taobao File System（TFS）。另外，分布式文件系统也常作为分布式表格系统以及分布式数据库的底层存储，如谷歌的GFS （Google File System，存储大文件）可以作为分布式表格系统Google Bigtable的底层存储，Amazon的EBS（Elastic Block Store，弹性块存储）系统可以作为分布式数据库（Amazon RDS）的底层存储。
　　总体上看，分布式文件系统存储三种类型的数据：Blob对象、定长块以及大文件。在系统实现层面，分布式文件系统内部按照数据块（chunk）来组织数据，每个数据块的大小大致相同，每个数据块可以包含多个Blob对象或者定长块，一个大文件也可以拆分为多个数据块，如图1-1所示。分布式文件系统将这些数据块分散到存储集群，处理数据复制、一致性、负载均衡、容错等分布式系统难题，并将用户对Blob对象、定长块以及大文件的操作映射为对底层数据块的操作。
　　图1-1数据块与Blob对象、定长块、大文件之间的关系
　　2．分布式键值系统
　　分布式键值系统用于存储关系简单的半结构化数据，它只提供基于主键的CRUD（Create/Read/Update/Delete）功能，即根据主键创建、读取、更新或者删除一条键值记录。
　　典型的系统有Amazon Dynamo以及Taobao Tair。从数据结构的角度看，分布式键值系统与传统的哈希表比较类似，不同的是，分布式键值系统支持将数据分布到集群中的多个存储节点。分布式键值系统是分布式表格系统的一种简化实现，一般用作缓存，比如淘宝 Tair以及Memcache。一致性哈希是分布式键值系统中常用的数据分布技术，因其被Amazon DynamoDB系统使用而变得相当有名。
　　3．分布式表格系统
　　分布式表格系统用于存储关系较为复杂的半结构化数据，与分布式键值系统相比，分布式表格系统不仅仅支持简单的CRUD操作，而且支持扫描某个主键范围。分布式表格系统以表格为单位组织数据，每个表格包括很多行，通过主键标识一行，支持根据主键的CRUD功能以及范围查找功能。
　　分布式表格系统借鉴了很多关系数据库的技术，例如支持某种程度上的事务，比如单行事务，某个实体组（Entity Group，一个用户下的所有数据往往构成一个实体组）下的多行事务。典型的系统包括Google Bigtable以及Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等。与分布式数据库相比，分布式表格系统主要支持针对单张表格的操作，不支持一些特别复杂的操作，比如多表关联，多表联接，嵌套子查询；另外，在分布式表格系统中，同一个表格的多个数据行也不要求包含相同类型的列，适合半结构化数据。分布式表格系统是一种很好的权衡，这类系统可以做到超大规模，而且支持较多的功能，但实现往往比较复杂，而且有一定的使用门槛。
　　4．分布式数据库
　　分布式数据库一般是从单机关系数据库扩展而来，用于存储结构化数据。分布式数据库采用二维表格组织数据，提供SQL关系查询语言，支持多表关联，嵌套子查询等复杂操作，并提供数据库事务以及并发控制。
　　典型的系统包括MySQL数据库分片（MySQL Sharding）集群，Amazon RDS以及Microsoft SQL Azure。分布式数据库支持的功能最为丰富，符合用户使用习惯，但可扩展性往往受到限制。当然，这一点并不是绝对的。Google Spanner系统是一个支持多数据中心的分布式数据库，它不仅支持丰富的关系数据库功能，还能扩展到多个数据中心的成千上万台机器。除此之外，阿里巴巴OceanBase系统也是一个支持自动扩展的分布式关系数据库。
　　关系数据库是目前为止最为成熟的存储技术，它的功能极其丰富，产生了商业的关系数据库软件（例如Oracle，Microsoft SQL Server，IBM DB2，MySQL）以及上层的工具及应用软件生态链。然而，关系数据库在可扩展性上面临着巨大的挑战。传统关系数据库的事务以及二维关系模型很难高效地扩展到多个存储节点上，另外，关系数据库对于要求高并发的应用在性能上优化空间较大。为了解决关系数据库面临的可扩展性、高并发以及性能方面的问题，各种各样的非关系数据库风起云涌，这类系统成为NoSQL系统，可以理解为“Not Only SQL”系统。NoSQL系统多得让人眼花缭乱，每个系统都有自己的独到之处，适合解决某种特定的问题。这些系统变化很快，本书不会尝试去探寻某种NoSQL系统的实现，而是从分布式存储技术的角度探寻大规模存储系统背后的原理。
　　第一篇
　　基础篇
　　本篇内容
　　第2章单机存储系统
　　第3章分布式系统
　　第2章单机存储系统
　　单机存储引擎就是哈希表、B树等数据结构在机械磁盘、SSD等持久化介质上的实现。单机存储系统是单机存储引擎的一种封装，对外提供文件、键值、表格或者关系模型。单机存储系统的理论来源于关系数据库。数据库将一个或多个操作组成一组，称作事务，事务必须满足原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）以及持久性（Durability），简称为ACID特性。多个事务并发执行时，数据库的并发控制管理器必须能够保证多个事务的执行结果不能破坏某种约定，如不能出现事务执行到一半的情况，不能读取到未提交的事务，等等。为了保证持久性，对于数据库的每一个变化都要在磁盘上记录日志，当数据库系统突然发生故障，重启后能够恢复到之前一致的状态。
　　本章首先介绍CPU、IO、网络等硬件基础知识及性能参数，接着介绍主流的单机存储引擎。其中，哈希存储引擎是哈希表的持久化实现，B树存储引擎是B树的持久化实现，而LSM树（Log Structure Merge Tree）存储引擎采用批量转储技术来避免磁盘随机写入。最后，介绍关系数据库理论基础，包括事务、并发控制、故障恢复、数据压缩等。
　　2.1硬件基础
　　硬件发展很快，摩尔定律告诉我们：每18个月计算机等IT产品的性能会翻一番；或者说相同性能的计算机等IT产品，每18个月价钱会降一半。但是，计算机的硬件体系架构保持相对稳定。架构设计很重要的一点就是合理选择并且能够最大限度地发挥底层硬件的价值。
　　2.1.1CPU架构
　　早期的CPU为单核芯片，工程师们很快意识到，仅仅提高单核的速度会产生过多的热量且无法带来相应的性能改善。因此，现代服务器基本为多核或多个CPU。经典的多CPU架构为对称多处理结构（Symmetric Multi-Processing，SMP），即在一个计算机上汇集了一组处理器，它们之间对称工作，无主次或从属关系，共享相同的物理内存及总线，如图2-1所示。
　　图2-1SMP系统结构
　　图2-1中的SMP系统由两个CPU组成，每个CPU有两个核心（core），CPU与内存之间通过总线通信。每个核心有各自的L1d Cache（L1数据缓存）及L1i Cache（L1指令缓存），同一个CPU的多个核心共享L2以及L3缓存，另外，某些CPU还可以通过超线程技术（Hyper-Threading Technology）使得一个核心具有同时执行两个线程的能力。
　　SMP架构的主要特征是共享，系统中所有资源（CPU、内存、I/O等）都是共享的，由于多CPU对前端总线的竞争，SMP的扩展能力非常有限。为了提高可扩展性，现在的主流服务器架构一般为NUMA（Non-Uniform Memory Access，非一致存储访问）架构。它具有多个NUMA节点，每个NUMA节点是一个SMP结构，一般由多个CPU（如4个）组成，并且具有独立的本地内存、IO槽口等。
　　图2-2为包含4个NUMA节点的服务器架构图，NUMA节点可以直接快速访问本地内存，也可以通过NUMA互联互通模块访问其他NUMA节点的内存，访问本地内存的速度远远高于远程访问的速度。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同NUMA节点之间的信息交互。
　　2.1.2IO总线
　　存储系统的性能瓶颈一般在于IO，因此，有必要对IO子系统的架构有一个大致的了解。以Intel x48主板为例，它是典型的南、北桥架构，如图2-3所示。北桥芯片通过前端总线（Front Side Bus，FSB）与CPU相连，内存模块以及PCI-E设备（如高端的SSD设备Fusion-IO）挂接在北桥上。北桥与南桥之间通过DMI连接，DMI的带宽为1GB/s，网卡（包括千兆以及万兆网卡），硬盘以及中低端固态盘（如Intel 320系列SSD）挂接在南桥上。如果采用SATAZ接口，那么最大带宽为300MB/s。
　　图2-2NUMA架构示例
　　图2-3Intel X48主板南北桥架构
　　2.1.3网络拓扑
　　图2-4为传统的数据中心网络拓扑，思科过去一直提倡这样的拓扑，分为三层，最下面是接入层（Edge），中间是汇聚层（Aggregation），上面是核心层（Core）。典型的接入层交换机包含48个1Gb端口以及4个10Gb上行端口，汇聚层以及核心层的交换机包含128个10Gb的端口。传统三层结构的问题在于可能有很多接入层的交换机接到汇聚层，很多的汇聚层交换机接到核心层。同一个接入层下的服务器之间带宽为1Gb，不同接入层交换机下的服务器之间的带宽小于1Gb。由于同一个接入层的服务器往往部署在一个机架内，因此，设计系统的时候需要考虑服务器是否在一个机架内，减少跨机架拷贝大量数据。例如，Hadoop HDFS默认存储三个副本，其中两个副本放在同一个机架，就是这个原因。
　　图2-4数据中心网络拓扑（三层结构）
　　为了减少系统对网络拓扑结构的依赖，Google在2008年的时候将网络改造为扁平化拓扑结构，即三级CLOS网络，同一个集群内最多支持20480台服务器，且任何两台都有1Gb带宽。CLOS网络需要额外投入更多的交换机，带来的好处也是明显的，设计系统时不需要考虑底层网络拓扑，从而很方便地将整个集群做成一个计算资源池。
　　同一个数据中心内部的传输延时是比较小的，网络一次来回的时间在1毫秒之内。数据中心之间的传输延迟是很大的，取决于光在光纤中的传输时间。例如，北京与杭州之间的直线距离大约为1300公里，光在信息传输中走折线，假设折线距离为直线距离的1.5倍，那么光传输一次网络来回延时的理论值为1300 × 1.5 ×2 / 300 000= 13毫秒，实际测试值大约为40毫秒。
　　2.1.4性能参数
　　常见硬件的大致性能参数如表2-1所示。
　　表2-1常用硬件性能参数
　　类别 消耗的时间
　　访问L1 Cache 0.5 ns
　　分支预测失败 5 ns
　　访问L2 Cache 7 ns
　　Mutex加锁/解锁 100 ns
　　内存访问 100 ns
　　千兆网络发送1MB数据 10 ms
　　从内存顺序读取1MB数据 0.25 ms
　　机房内网络来回 0.5 ms
　　异地机房之间网络来回 30~100 ms
　　SATA磁盘寻道 10 ms
　　从SATA磁盘顺序读取1MB数据 20 ms
　　固态盘SSD访问延迟 0.1~0.2 ms
　　磁盘读写带宽还是不错的，15000转的SATA盘的顺序读取带宽可以达到100MB以上，由于磁盘寻道的时间大约为10ms，顺序读取1MB数据的时间为：磁盘寻道时间 + 数据读取时间，即10ms + 1MB / 100MB/s×1000 = 20ms。存储系统的性能瓶颈主要在于磁盘随机读写。设计存储引擎的时候会针对磁盘的特性做很多的处理，比如将随机写操作转化为顺序写，通过缓存减少磁盘随机读操作。
　　固态磁盘（SSD）在最近几年得到越来越多的关注，各大互联网公司都有大量基于SSD的应用。SSD的特点是随机读取延迟小，能够提供很高的IOPS（每秒读写，Input/Output Per Second）性能。它的主要问题在于容量和价格，设计存储系统的时候一般可以用来做缓存或者性能要求较高的关键业务。
　　不同的持久化存储介质对比如表2-2所示。
　　表2-2存储介质对比
　　类别 每秒读写（IOPS）次数 每GB价格（元） 随机读取 随机写入
　　内存 千万级 150 友好 友好
　　SSD盘 35000 20 友好 写入放大问题
　　SAS磁盘 180 3 磁盘寻道 磁盘寻道
　　SATA磁盘 90 0.5 磁盘寻道 磁盘寻道
　　从表2-2可以看出，SSD单位成本提供的IOPS比传统的SAS或者SATA磁盘都要大得多，而且SSD功耗低，更加环保，适合小数据量并且对性能要求更高的场景。
　　2.1.5存储层次架构
　　从分布式系统的角度看，整个集群中所有服务器上的存储介质（内存、机械硬盘，SSD）构成一个整体，其他服务器上的存储介质与本机存储介质一样都是可访问的，区别仅仅在于需要额外的网络传输及网络协议栈等访问开销。
　　如图2-5所示，假设集群中有30个机架，每个机架接入40台服务器，同一个机架的服务器接入到同一个接入交换机，不同机架的服务器接入到不同的接入交换机。每台服务器的内存为24GB，磁盘为10×1TB的SATA机械硬盘（15000转）或者10×160GB的SSD固态硬盘。那么，对于每台服务器，本地内存大小为24GB，访问延时为100ns，本地SATA磁盘的大小为4TB（假设利用率为40%），随机访问的寻道时间为10ms，本地SSD磁盘的大小为1TB（假设利用率为60%），访问延时为0.1ms，SATA磁盘和SSD的访问带宽受限于SATA接口，最大不超过300MB/s。同一个机架下的服务器的内存总量大致为1TB，访问延时和带宽受限于网络，访问延时大约为300μs，带宽为100MB/s，磁盘总容量为160TB，访问延时为网络延时加上磁盘寻道时间，大约为11ms，SSD容量为40TB，访问延时为网络延时加上SSD访问延时，大约为2ms。整个集群下所有服务器的内存总量为30TB，访问延时和带宽受限于网络，跨机架访问需要经过聚合层或者核心层的交换机，访问延时大约为500μs，带宽大约为10MB/s，磁盘和SSD的访问延时分别为11ms以及2ms，带宽为10MB/s。
　　图2-5存储层次结构图
　　存储系统的性能主要包括两个维度：吞吐量以及访问延时，设计系统时要求能够在保证访问延时的基础上，通过最低的成本实现尽可能高的吞吐量。磁盘和SSD的访问延时差别很大，但带宽差别不大，因此，磁盘适合大块顺序访问的存储系统，SSD适合随机访问较多或者对延时比较敏感的关键系统。二者也常常组合在一起进行混合存储，热数据（访问频繁）存储到SSD中，冷数据（访问不频繁）存储到磁盘中。