本书将以电商应用场景为例，讲解不同规模的存储系统应该如何构建。本书的章节是按照系统的发展过程来设计，分成了设计篇、高速增长篇、海量数据篇和技术进阶篇。在设计篇中，重点介绍如何从0到1地设计电商系统的各个存储架构。在高速增长篇中，重点关注在高速变化的过程中系统所遇到的共通性问题，以及应对这些问题的方法。在海量数据篇中，重点解决高并发、海量数据情况下的存储系统应该如何设计的问题。在技术进阶篇中，重点探讨在存储技术领域，有哪些新技术值得关注，哪些技术可能成为未来的发展趋势。毕竟，不断创新是技术发展的原动力。
电商
存储系统实战
李玥◎著
架构设计与海量数据处理
基于实战案例系统地讲解电商系统的存储设计，
详细分析不同规模存储系统的构建方法
每章解决一两个实战中的高频问题，
帮你快速应对各种电商存储系统难题，深入理解存储系统知识和原理
E-COMMERCE
STORAGE SYSTEM
IN ACTION
Architecture Design and Massive Data Processing
换一种方式学习存储系统
你好，我是李玥，很高兴在这里遇见你。
我的从业经历比较丰富，曾在传统IT行业做过大量的企业级toB系统，转战互联网后，又曾带领创业团队体验过从0到1创业的艰辛，见证过互联网高速增长的高光时刻，也经历过数年电商大促的洗礼。近年来，我主要从事基础架构领域（包括一些存储系统和中间件等）的技术工作。简单地说，我是一个“造轮子”的程序员。
在工作过程中，我接触过很多系统。不同系统的业务各不相同，有做社交的，有做电商的，还有做内容的。规模也大小不一，有的系统规模很小，也有像BAT使用的“巨无霸”系统。在构建这些系统时，我遇到过各种各样的问题。但总结之后我发现了一个“神奇”的规律：凡是那些特别难解决的、需要付出巨大代价的，或者损失惨重的技术问题，几乎都可以归结为存储系统的问题。
其实，这个规律并不神奇，它也是有原因的。
总体来说，各种业务系统几乎都属于MIS（管理信息系统，有的大学还开设了这个专业）范畴。顾名思义，管理信息系统就是管理信息的系统。这里的信息其实就是数据。不管系统的业务是什么，最终都要落到对信息的管理上，通俗地说，系统最终的业务功能都会落到数据上。
只要数据是正确的，其他的问题基本上都是小问题。数据错了、丢了，以及数据处理不及时，才是会造成惨重损失的大问题。
可见，用于承载数据的存储系统非常重要，如果能够构建一个安全可靠、快速稳定的存储系统，那么在该基础之上构建的业务系统，才能让人更为放心。
综上所述，存储是系统中最重要、最关键的组成部分，没有之一。
需要关注存储系统的哪些特点
我们常用的存储系统种类非常多，有单机的也有分布式的，有的是数据库，有的是文件系统，还有介于二者之间的。无论是哪种存储系统（比如，MySQL、Redis、Elasticsearch，等等），它们都具有如下三个特点。
第一个特点是难用。难用体现在哪些方面呢？对于应用程序来说，存储的作用是安全可靠地保存数据，在我们需要的时候能够快速存取。遗憾的是，目前几乎没有一种存储系统能够满足这个简单的要求。
对于存储系统难用的特性，业内有一个非常形象的比喻：开着车去商场购物，到了停车场发现这里不能存车，只能存零件，必须先把车子拆散，然后把这些零件分门别类地打上标签存放到停车场对应的货架上，走的时候再把零件逐一取出来进行组装。
听起来似乎很可笑，但是仔细想想我们正在使用的这些存储系统，其提供的功能就是如此。应用程序里管理的数据都是对象，但是，大多数存储系统不能直接存储对象。下面就以MySQL为例进行说明。存取一个对象时，必须把对象转换成MySQL表中的行，还得编写SQL语句才能完成存取操作。是不是很难用？不仅难用，而且还必须用好。要想用好，需要学习和掌握其中的方法和技巧。
第二个特点是慢。近年来，分布式存储在业内的发展非常迅速，每隔一段时间就会诞生一种新的数据库，不管功能如何，它们无一例外都会与MySQL这样的传统数据库进行性能测试对比，以彰显自己速度快、性能好。
不过，有句俗话：“一个人越炫耀什么，说明内心越缺少什么。”这句话也同样适用于技术圈。不断有新的存储系统刷新性能纪录，恰恰说明了现有的存储系统性能不尽如人意。经过良好优化的业务系统，其性能瓶颈一定是存储。从性能的角度来说，存储系统就是整个系统中最短的那块板，存储系统有多慢，整个系统就会有多慢。如何优化存储性能，从而让整个系统运转如飞，这其中包含了很多方法、技巧和经验，需要我们学习和掌握。
第三个特点是杂。存储与其他成熟的技术领域不同，后者基本上都是以一两种方案为主，比如，Java开发基本上是以Spring为主，再比如，开发中使用的Web容器，存放静态页面以Nginx为主，存放动态页面以Tomcat为主。但存储大不相同，目前已有的广泛应用于生产系统中的存储系统的种类非常多。
MySQL、Redis、Elasticsearch、HBase、Hive、MongoDB、CockroachDB和S3等，这些存储系统谁都替代不了谁，每一种都有其所擅长的地方和适用的场景，当然也有其突出的短板。因此，我们需要学习和掌握如何根据业务系统的特点选择合适的存储系统来构建我们的系统。
学习存储系统的最佳实践
由于存储系统具有“难用、慢、杂”这几大特点，因此我们学习起来更需要注重方法。如何学习才能更为高效呢？答案是实践，从问题入手。
存储涉及大量的理论知识和概念，比如，构成存储引擎的哈希表、树等数据结构，以及这些数据结构的时间复杂度，这些往往都是偏理论范畴的知识，学习起来不容易理解和记忆。并且，理论和实践之间往往存在非常大的差距，“懂了一堆道理，却还是写不好代码”是一个很普遍的现象。
我撰写的这本书将会为大家讲解实践中经常会遇到的各种问题，以及对应的解决方法，同时还会穿插相应的知识和原理解说。希望这种学习方式，既可以帮读者快速解决实际问题，又能帮读者提升相应的技能，进而在存储系统的技术领域构建自己的知识框架。
本书将以电商应用场景为例，从0到1讲解应该如何构建不同规模的存储系统。
书中每章都会解决一两个实战问题，比如：为什么在数据量和访问量都不大的情况下，MySQL还是很慢？数据库宕机了应该怎么办？等等。
为什么本书要以电商系统为例进行讲解呢？因为电商系统具有很强的代表性，特别适合作为研究和学习的案例。不仅是本书，很多培训学校、技术论坛也都特别喜欢讨论电商系统。
首先，电商系统的覆盖面足够广。特别是在互联网行业，几乎所有的公司都在做两件事情：电商和社交。
其次，以电商系统作为案例，直接就能学以致用。因为电商系统具有很高的复杂性，所以你在其他业务中可能遇到的技术问题，在电商系统中基本上都会遇到，即使你面对的业务与电商关系不大，也一样具有借鉴意义。
最后，所有人都很熟悉电商业务领域。以电商系统作为案例，基本上不需要再讲解相关的业务知识，我们可以快速专注于技术问题本身。
即使是同一个电商系统，不同的规模所需要解决的问题也不一样。不少技术人员崇尚海量数据和高并发，认为只有大企业的高并发、海量数据的核心系统或者底层存储系统，才是真正“有技术含量”的系统，能胜任这种系统的开发者，才是真正的技术能人。这其实是一种对技术认知的误解。为什么这么说呢？因为并不是规模小的系统就简单，规模大的系统才有难度。
创业团队需要快速、低成本地实现完整的系统，以便快速验证其商业模式。处于高速增长期的团队，所面临的问题主要是业务的高速增长和不断变化，相应地，团队也要对系统不停地进行升级改造来适应变化，并且在变化的过程中要确保系统的稳定性。至于业务规模足够大的企业，它们需要解决的问题是如何应对高并发的海量数据。
所以说，不同规模的系统，在技术上并没有难易之说，更没有高低贵贱之分，它们的建设目标不一样，所面临的挑战不一样，需要解决的问题也不一样，对于存储系统的选择和架构设计自然也是不一样的。
本书的章节设计就是按照系统的发展过程，分成设计、高速增长、海量数据和技术展望四篇。
在设计篇中，我们将重点解决从0到1的问题。例如，如何低成本、高质量地快速构建一个小规模的订单存储系统。
在高速增长篇中，我们将重点关注在快速变化的过程中系统所遇到的共通问题，以及应对这些问题的方法。例如，如何从单机存储系统逐步演进为分布式存储系统，如何在线平滑地扩容存储系统。
在海量数据篇中，我们将重点解决在高并发、海量数据的情况下应该如何设计存储系统的问题。例如，如何存储海量的埋点数据，如何在各种数据库之间实时地迁移和同步海量数据，等等。
在技术展望篇中，我们将重点探讨在存储技术领域，有哪些新技术值得关注，哪些技术可能会成为未来的发展趋势，等等。毕竟，不断创新是技术发展的原动力。
读完本书后，你不仅可以学习到案例中那些解决具体问题的方法，而且在电商系统架构、存储系统的设计等方面，也会有所收获。
更重要的是，通过案例来学习常用的数据库和存储系统的实现与使用方法，有助于我们更好地总结存储系统最通用、最本质的技术原理。了解了存储系统的本质，我们不仅会在应对问题时更加从容，而且会对存储的理解上升一个层次，从“知道怎么用”升级为“知道为什么这样用”，最终做到“活学活用”。
一段新旅程即将开始，在开始正式学习之前，我还想再说一下我的想法：技术的发展使技术的使用变得越来越简单，但是作为有理想、有情怀的开发者，不能让技术把我们变得越来越“简单”。很开心能与大家一起开始这段旅程，持续地丰富自己，也希望我们都能不负时光，认真对待这段学习之旅。
计算机\程序设计
存储是系统中最核心、最重要的组成部分，但分布式存储技术却具有难用、慢和杂等特点。存储系统的应用场景很复杂，主流的存储技术各有所长，单纯学习理论知识，很难针对实际问题得出最优解决方案。本书以电商不同发展阶段的问题场景为蓝本，帮助读者从实战中理解“存储”，关注实践中大家都会遇到的问题，详细讲解这些问题的解决方法，同时贯穿相关知识和原理。通过阅读本书，你不仅可以快速解决实际工作中各种规模下的电商系统问题，还能深入理解存储系统架构设计。
阅读本书，你将获得：
电商存储中18个高频问题的解决方案。
不同业务场景下的存储选型策略。
分布式存储领域的前沿技术。
电商存储技术的核心原理和实现。
前言 换一种方式学习存储系统
第一篇 设计
第1章 如何设计电商系统 3
1.1 设计电商系统的核心流程 4
1.2 根据流程划分功能模块 6
1.3 小结 9
1.4 思考题 10
第2章 订单系统的设计：确保订单数据的准确性 11
2.1 订单系统的核心功能和数据 12
2.2 如何避免重复下单 13
2.3 如何解决ABA问题 16
2.4 小结 18
2.5 思考题 19
第3章 商品系统的存储架构设计 20
3.1 商品系统需要保存哪些数据 21
3.2 如何存储商品的基本信息 22
3.3 使用MongoDB保存商品参数 23
3.4 使用对象存储保存图片和视频 24
3.5 将商品介绍静态化 25
3.6 小结 26
3.7 思考题 28
第4章 购物车系统的存储架构：前后端混合存储 29
4.1 设计购物车系统的存储架构时需要把握什么原则 30
4.2 如何设计“暂存购物车”的存储 32
4.3 如何设计“用户购物车”的存储 34
4.4 小结 36
4.5 思考题 37
第5章 账户系统：用事务解决对账问题 38
5.1 为什么总是对不上账 39
5.2 使用数据库事务保证数据的一致性 40
5.3 理解事务的隔离级别 42
5.4 小结 49
5.5 思考题 50
第6章 分布式事务：保证多个系统间的数据一致 51
6.1 什么是分布式事务 52
6.2 2PC：订单与优惠券的数据一致性问题 53
6.3 本地消息表：订单与购物车的数据一致性问题 57
6.4 小结 59
6.5 思考题 59
第7章 用Elasticsearch构建商品搜索系统 60
7.1 理解倒排索引机制 60
7.2 如何在ES中构建商品的索引 63
7.3 小结 67
7.4 思考题 68
第8章 备份与恢复 69
8.1 如何更安全地实现数据备份和恢复 70
8.2 配置MySQL HA实现高可用性 73
8.3 小结 75
8.4 思考题 76
第二篇 高速增长
第9章 优化SQL 79
9.1 每个系统必踩的“坑”：访问数据库超时 79
9.1.1 事故排查过程 79
9.1.2 如何避免悲剧重演 85
9.1.3 小结 87
9.1.4 思考题 88
9.2 如何避免写出“慢SQL” 88
9.2.1 定量认识MySQL 88
9.2.2 使用索引避免全表扫描 90
9.2.3 分析SQL执行计划 92
9.2.4 小结 93
9.2.5 思考题 94
9.3 SQL在数据库中的执行 94
9.3.1 SQL在执行器中是如何执行的 95
9.3.2 SQL在存储引擎中是如何执行的 98
9.3.3 小结 100
9.3.4 思考题 101
第10章 MySQL应对高并发 102
10.1 使用缓存保护MySQL 102
10.1.1 更新缓存的最佳方式 103
10.1.2 注意避免缓存穿透引起雪崩 105
10.1.3 小结 107
10.1.4 思考题 107
10.2 读写分离 107
10.2.1 读写分离是提升MySQL并发能力的首选方案 108
10.2.2 注意读写分离带来的数据不一致问题 111
10.2.3 小结 112
10.2.4 思考题 113
10.3 实现MySQL主从数据库同步 113
10.3.1 如何配置MySQL的主从同步 113
10.3.2 复制状态机：所有分布式存储都是这样复制数据的 116
10.3.3 小结 117
10.3.4 思考题 118
第三篇 海量数据
第11章 MySQL应对海量数据 121
11.1 归档历史数据 121
11.1.1 存档历史订单数据提升查询性能 122
11.1.2 如何批量删除大量数据 124
11.1.3 小结 127
11.1.4 思考题 128
11.2 分库分表 128
11.2.1 如何规划分库分表 129
11.2.2 如何选择分片键 130
11.2.3 如何选择分片算法 131
11.2.4 小结 133
11.2.5 思考题 134
第12章 缓存海量数据 135
12.1 用Redis构建缓存集群的最佳实践 135
12.1.1 Redis Cluster如何应对海量数据、高可用和高并发问题 136
12.1.2 为什么Redis Cluster不适合超大规模集群 138
12.1.3 如何用Redis构建超大规模集群 139
12.1.4 小结 141
12.1.5 思考题 142
12.2 大型企业如何实现MySQL到Redis的同步 142
12.2.1 缓存穿透：超大规模系统的不能承受之痛 142
12.2.2 使用Binlog实时更新Redis缓存 144
12.2.3 小结 149
12.2.4 思考题 150
12.3 基于Binlog实现跨系统实时数据同步 150
12.3.1 使用Binlog和消息队列构建实时数据同步系统 151
12.3.2 如何保证数据同步的实时性 152
12.3.3 小结 154
12.3.4 思考题 154
第13章 更换数据库 155
13.1 如何实现不停机更换数据库 155
13.2 如何实现比对和补偿程序 158
13.3 小结 160
13.4 思考题 160
第14章 对象存储：最简单的分布式存储系统 161
14.1 对象存储数据是如何保存大文件的 162
14.2 如何拆分和保存大文件对象 163
14.3 小结 166
14.4 思考题 167
第15章 海量数据的存储与查询 168
15.1 如何存储前端埋点之类的海量数据 168
15.1.1 使用Kafka存储海量原始数据 169
15.1.2 使用HDFS存储更大规模的数据 171
15.1.3 小结 173
15.1.4 思考题 173
15.2 面对海量数据，如何才能查得更快 173
15.2.1 常用的分析类系统应该如何选择存储 174
15.2.2 转变思想：根据查询选择存储系统 176
15.2.3 小结 178
15.2.4 思考题 178
第16章 存储系统的技术选型 179
16.1 技术选型时应该考虑哪些因素 180
16.2 在线业务系统如何选择存储产品 182
16.3 分析系统如何选择存储产品 183
16.4 小结 183
16.5 思考题 184
第四篇 技术展望
第17章 使用NewSQL解决高可用和分片难题 187
17.1 什么是NewSQL 187
17.2 CockroachDB如何实现数据分片和弹性扩容 188
17.3 CockroachDB能提供金融级的事务隔离性吗 190
17.4 小结 193
17.5 思考题 193
第18章 RocksDB：不丢数据的高性能KV存储 194
18.1 同样是KV存储，RocksDB有哪些不同 195
18.2 LSM-Tree如何兼顾读写性能 196
18.3 小结 199
18.4 思考题 199
附录A 测试题及解析 200
附录B 思考题解析 206
后记 让奋斗成为习惯 219
