qq_37756660的博客

最后一讲，聊聊对个人技术成长的感悟。程序员是一个特别依赖个人技术能力的职业，不同的程序员之间，技术能力的差别也非常大。一个大神程序员的产出，可以抵得上好几个普通程序员。一个技术差还自以为是的程序员，他的产出更是能抵得上几十个程序员，不过这个产出是负的。所谓一人写 Bug，大家加班来找茬，相信很多人都有过这样的经历。相应的，程序员的收入差距也非常大，从年入几万到几百万的都有。同样是应届生，从 CRUD（增删改查）开始做起，几年之后有些人还在“CRUD”，只是更熟练了而已。

上节我们在讲解 CockroachDB 的时候提到过，CockroachDB 的存储引擎是一个分布式的 KV 存储集群，它用了一系列成熟的技术来解决集群问题，但是在集群的每个节点上，还需要一个单机的 KV 存储来保存数据，这个地方 CockroachDB 直接使用 RocksDB 作为它的 KV 存储引擎。是 Facebook 开源的一个高性能持久化 KV 存储。目前，你可能很少见到过哪个项目会直接使用 RocksDB 来保存数据，在未来，RocksDB 大概率也不会像 Redis 那样被业务系统直接使用。

什么是 New SQL？这个说来话长了，还要从存储技术发展的历史来解读。我们知道，早期只有像 MySQL 这样的关系数据库，这种关系型数据库因为支持 SQL 语言，后来被叫做 SQL 或者 Old SQL。然后，出现了 Redis 和很多 KV 存储系统，性能上各种吊打 MySQL，而且因为存储结构简单，所以比较容易组成分布式集群，并且能够做到水平扩展、高可靠、高可用。因为这些 KV 存储不支持 SQL，为了以示区分，被统称为 No SQL。

我们接着上节的话题，来继续说海量数据。上节我们讲了，如何来保存原始数据，那我们知道，原始数据的数据量太大了，能存下来就很不容易了，这个数据是没法直接来给业务系统查询和分析的。有两个原因，一是数据量太大了，二是也没有很好的数据结构和查询能力，来支持业务系统查询。所以一般的做法是，用流计算或者是批计算，把原始数据再进行一次或者多次的过滤、汇聚和计算，把计算结果落到另外一个存储系统中去，由这个存储再给业务系统提供查询支持。

对于大部分互联网公司来说，数据量最大的几类数据是：点击流数据、监控数据和日志数据。这里面“点击流”指的是在 App、小程序和 Web 页面上的埋点数据，这些埋点数据记录用户的行为，比如你打开了哪个页面，点击了哪个按钮，在哪个商品上停留了多久等等这些。当然你不用太担心自己的隐私问题，记录的这些行为数据不是为了监控用户，主要目的是为了从统计上分析群体用户的行为，从而改进产品和运营。比如，某件商品看的人很多，停留时间很长，最后下单购买的人却很少，那采销人员就要考虑是不是这件商品的定价太高了。

随着我们的系统规模逐渐增长，总会遇到需要更换数据库的问题。我们来说几种常见的情况。对 MySQL 做了分库分表之后，需要从原来的单实例数据库迁移到新的数据库集群上。系统从传统部署方式向云上迁移的时候，也需要从自建的数据库迁移到云数据库上。一些在线分析类的系统，MySQL 性能不够用的时候，就需要更换成一些专门的分析类数据库，比如说 HBase。更换数据库这个事儿，是一个非常大的技术挑战，因为我们需要保证整个迁移过程中，既不能长时间停服，也不能丢数据。

我们在《15 | MySQL 存储海量数据的最后一招：分库分表》这节中讲过，数据量太大的时候，单个存储节点存不下，那就只能把数据分片存储。数据分片之后，我们对数据的查询就没那么自由了。比如订单表如果按照用户 ID 作为 Sharding Key 来分片，那就只能按照用户维度来查询。如果我是一个商家，我想查我店铺的订单，对不起，做不到了。（当然，强行查也不是不行，在所有分片上都查一遍，再把结果聚合起来，又慢又麻烦，实际意义不大。对于这样的需求，普遍的解决办法是用空间换时间，毕竟现在存储越来越便宜。

我们都知道，保存像图片、音视频这类大文件，最佳的选择就是对象存储。对象存储不仅有很好的大文件读写性能，还可以通过水平扩展实现近乎无限的容量，并且可以兼顾服务高可用、数据高可靠这些特性。对象存储之所以能做到这么“全能”，最主要的原因是，。这里我们讲的“原生分布式存储系统”，是相对于 MySQL、Redis 这类单机存储系统来说的。虽然这些非原生的存储系统，也具备一定的集群能力，但你也能感受到，用它们构建大规模分布式集群的时候，其实是非常不容易的。

之前我们在《11 | MySQL 如何应对高并发（一）：使用缓存保护 MySQL》这一节中，讲到了 Read/Write Through 和 Cache Aside 这几种更新缓存的策略，这几种策略都存在缓存穿透的可能，如果缓存没有命中，那就穿透缓存去访问数据库获取数据。一般情况下，只要我们做好缓存预热，这个缓存的命中率很高，能穿透缓存打到数据库上的请求比例就非常低，这些缓存的策略都是没问题的。但是如果说，我们的 Redis 缓存服务的是一个超大规模的系统，那就又不一样了。

之前连续几节，我们都在以 MySQL 为例子，讲如何应对海量数据，如何应对高并发，如何实现高可用，先简单复习一下。数据量太大查询慢怎么办？存档历史数据或者分库分表，这是数据分片。并发太高扛不住怎么办？读写分离，这是增加实例数。数据库宕机怎么办？增加从节点，主节点宕机的时候用从节点顶上，这是主从复制。但是这里面要特别注意数据一致性的问题。在之前，也多次提到过，。今天这节，我们来聊一聊，如何构建一个生产系统可用的 Redis 缓存集群。

从这节开始，我们将进入最后一部分“海量数据篇”，这节也是我们最后一节主要讲 MySQL 的课程。解决海量数据的问题，必须要用到分布式的存储集群，因为 MySQL 本质上是一个单机数据库，所以很多场景下不是太适合存 TB 级别以上的数据。但是，绝大部分的电商大厂，它的在线交易这部分的业务，比如说，订单、支付相关的系统，还是舍弃不了 MySQL，原因是，。我们之前也讲过分布式事务，那些新的分布式数据库提供的所谓的分布式事务，多少都有点儿残血，目前还达不到这些交易类系统对数据一致性的要求。

在前面几节，我们一起学习了在并发持续高速增长的情况下，如何来逐步升级存储。今天这节课我们来聊一聊，如何应对数据的持续增长，特别是像订单数据这种会随着时间一直累积的数据。为什么数据量越大数据库就越慢？你得理解这里面的根本原因。我们知道，无论是“增删改查”哪个操作，其实都是查找问题，因为你都得先找到数据才能对数据做操作。那存储系统性能问题，其实就是查找快慢的问题。无论是什么样的存储系统，一次查询所耗费的时间，都取决于两个因素：1. 查找的时间复杂度；2. 数据总量。

回顾我们之前讲 MySQL 相关的几节，会发现主从同步有多重要。解决数据可靠性的问题需要用到主从同步；解决 MySQL 服务高可用要用到主从同步；应对高并发的时候，还是要用到主从同步。我们在运维 MySQL 集群时，遇到的很多常见的问题，比如说，为什么从节点故障会影响到主节点？为什么主从切换之后丢数据了？为什么明明没有更新数据，客户端读到的数据还是变来变去的？这些都和主从同步的配置有密切的关系。

上节讲了，使用 Redis 作为 MySQL 的前置缓存，可以帮助 MySQL 挡住绝大部分的查询请求。这种方法对于像电商中的商品系统、搜索系统这类与用户关联不大的系统，效果特别的好。因为在这些系统中，每个人看到的内容都是一样的，也就是说，对后端服务来说，每个人的查询请求和返回的数据都是一样的。这种情况下，Redis 缓存的命中率非常高，近乎于全部的请求都可以命中缓存，相对的，几乎没有多少请求能穿透到 MySQL。

通过前面几节的学习，相信对 MySQL 这类关系型数据库的能力，已经有了定量的认知。我们知道，大部分面向公众用户的互联网系统，它的并发请求数量是和在线用户数量正相关的，而 MySQL 能承担的并发读写的量是有上限的，当系统的在线用户超过几万到几十万这个量级的时候，单台 MySQL 就很难应付了。绝大多数互联网系统，都使用 MySQL 加上 Redis 这对儿经典的组合来解决这个问题。

上一节我们讲了怎么来避免写出慢 SQL，留了一道思考题：在下面这两个 SQL 中，为什么第一个 SQL 在执行的时候无法命中索引呢？原因是，这个 SQL 的 WHERE 条件中对 department_code 这个列做了一个 left 截取的计算，对于表中的每一条数据，都得先做截取计算，然后判断截取后的值，所以不得不做全表扫描。你在写 SQL 的时候，尽量不要在 WEHER 条件中，对列做任何计算。到这里这个问题就结束了么？

通过上节的案例，我们知道，一个慢 SQL 就可以直接让 MySQL 瘫痪。今天这节课，我们一起看一下，怎么才能避免写出危害数据库的慢 SQL。所谓慢 SQL，就是执行特别慢的 SQL 语句。什么样的 SQL 语句是慢 SQL？多慢才算是慢 SQL？并没有一个非常明确的标准或者说是界限。但并不是说，我们就很难区分正常的 SQL 和慢 SQL，在大多数实际的系统中，慢 SQL 消耗掉的数据库资源，往往是正常 SQL 的几倍、几十倍甚至几百倍，所以还是非常容易区分的。

每一个创业公司，它的系统随着公司的发展一起成长的过程中，都难免会发生一些故障或者是事故，严重的会影响业务。搞技术的同学管这个叫：坑儿，分析解决问题的过程，称为：填坑儿。而访问数据库超时这个坑儿，是我见过的被踩的次数最多的一个坑儿，并且这个坑儿还在被不停地踩来踩去。今天这节，分享一个典型的数据库超时案例。也希望通过一起分析这个案例，一是，吸取其中的经验教训，日后不要再踩类似的坑儿；二是，如果遇到类似的问题，能掌握分析方法，快速地解决问题。

对于任何一个企业来说，数据安全的重要性是不言而喻的。在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。能够影响数据安全的事件，都是极小概率的事件，比如说：数据库宕机、磁盘损坏甚至机房着火，还有最近频繁出现在段子中“程序员不满老板删库跑路”的梗儿，但这些事儿一旦发生了，我们的业务就会损失惨重。一般来说，存储系统导致的比较严重的损失主要有两种情况，一是数据丢失造成的直接财产损失，比如大量的坏账；二是由于存储系统损坏，造成整个业务系统停止服务而带来的损失。

搜索这个特性可以说是无处不在，现在很少有网站或者系统不提供搜索功能了，所以，即使你不是一个专业做搜索的程序员，也难免会遇到一些搜索相关的需求。搜索这个东西，表面上看功能很简单，就是一个搜索框，输入关键字，然后搜出来想要的内容就好了。搜索背后的实现，可以非常简单，简单到什么程度呢？我们就用一个 SQL，LIKE 一下就能实现；也可以很复杂，复杂到什么程度呢？不说百度谷歌这种专业做搜索的公司，其他非专业做搜索的互联网大厂，搜索团队大多是千人规模，这里面不仅有程序员，还有算法工程师、业务专家等等。

在学习分布式事务这个概念之前，先说一下为什么一定要搞懂概念。我们这是一门实战课，一般来说，我们更关注的是如何来解决实际问题，而不是理论和概念，所以你看，我们在讲解数据库事务的时候，讲的内容是如何用事务解决交易的问题，而没讲 MySQL 是如何实现 ACID 的。因为数据库已经把事务封装的非常好了，我们只需要掌握如何使用就可以很好地解决问题。但分布式事务不是这样的，刚刚说了，并没有一种分布式事务的服务或者组件，能帮我们很简单地就解决分布式系统下的数据一致性问题。

今天这节我们来说一下电商的账户系统。账户系统负责记录和管理用户账户的余额，这个余额就是每个用户临时存在电商的钱，来源可能是用户充值或者退货退款等多种途径。账户系统的用途也非常广泛，不仅仅是电商，各种互联网内容提供商、网络游戏服务商，电信运营商等等，都需要账户系统来管理用户账户的余额，或者是虚拟货币。包括银行的核心系统，也同样包含一个账户系统。从业务需求角度来分析，一个最小化的账户系统，它的数据模型可以用下面这张表来表示：这个表包括用户 ID、账户余额和更新时间三个字段。

今天这节我们来说一下购物车系统的存储该如何设计。首先，我们来看购物车系统的主要功能是什么。就是在用户选购商品时，下单之前，暂存用户想要购买的商品。购物车对数据可靠性要求不高，性能也没有特别的要求，在整个电商系统中，看起来是相对比较容易设计和实现的一个子系统。购物车系统的功能，主要的就三个：把商品加入购物车（后文称“加购”）、购物车列表页、发起结算下单，再加上一个在所有界面都要显示的购物车小图标。支撑购物车的这几个功能，对应的存储模型应该怎么设计？很简单，只要一个“购物车”实体就够了。

商品介绍在商详页中占得比重是最大的，包含了大量的带格式文字、图片和视频。其中图片和视频自然要存放在对象存储里面，商品介绍的文本，一般都是随着商详页一起静态化，保存在 HTML 文件中。什么是静态化呢？静态化是相对于动态页面来说的。一般我们部署到 Tomcat 中的 Web 系统，返回的都是动态页面，也就是在 Web 请求时，动态生成的。比如说商详页，一个 Web 请求过来，带着 SKUID，Tomcat 中的商详页模块，再去访问各种数据库、调用后端服务，动态把这个商详页拼出来，返回给浏览器。

订单系统是整个电商系统中最重要的一个子系统，订单数据也就是电商企业最重要的数据资产。今天这节，来说一下，在设计和实现一个订单系统的存储过程中，有哪些问题是要特别考虑的。一个合格的订单系统，最基本的要求是什么？。一个购物流程，从下单开始、支付、发货，直到收货，这么长的一个流程中，每一个环节，都少不了更新订单数据，每一次更新操作又需要同时更新好几张表。这些操作可能被随机分布到很多台服务器上执行，服务器有可能故障，网络有可能出问题。在这么复杂的情况下，保证订单数据一笔都不能错，是不是很难？

在这个系列中，我们会讲电商这个行业在多年系统建设和运维过程中，总结出来的使用分布式存储系统的一些最佳实践。也会以电商系统作为例子来讲解存储相关的技术知识和问题。这都需要对电商的业务逻辑、系统架构、核心业务流程有一个基本的认知。虽然说，电商这个业务和你的生活息息相关，可能对电商多少有一些了解，但是，即使是一个最小化的电商系统，它仍然非常复杂。所以，我们先花一节的时间，一起以一个创业公司的 CTO 的视角，设计一个最小化的电商系统，在这个过程中帮你理清楚电商系统的架构。

在工作过程中，接触过很多系统。不同的系统，它的业务不一样，有做社交的，有做电商的，还有做内容的。系统的规模也不一样，有很小规模的系统，也有像 BAT 这样的巨无霸系统。在构建这些系统时，都会面临五花八门的问题。这个规律其实并不神奇，它是有原因的。可以想一下，我们开发的各种业务系统，几乎都是 MIS 系统，中文叫“管理信息系统”，有的大学还有这个专业。管理信息系统这个词的含义就是字面的意思：管理信息的系统。这里面的信息是什么？对，其实就是数据。