MySQL中间件性能测试 I

本文根据黄炎在2018年7月7日【MySQL技术沙龙 · 成都站】现场演讲内容整理而成。

黄炎
爱可生研发总监，深刻钻研分布式数据库相关技术，擅长业界相关MySQL中间件产品和开发，以及分布式中间件在企业内部的应用实践。

MySQL中间件性能测试 I

摘要：我今天表明个人团队向你们来介绍一下MySQL中间件性能的测试，为你们带来一些不太同样的故事，包括咱们在作性能测试的时候一些不太同样的视角。

分享大纲：

1.性能测试的常见的(错误)方法 * 3
2.性能测试的一些(咱们用的)方法 * 2
3.分布式事务相关 * 1

我今天表明个人团队向你们来介绍一下MySQL中间件性能的测试，之因此讲选这个主题是由于我注意到你们都是高级的DBA，咱们也有不少的高级的DBA，跟你们聊天的时候都会注意到，你们对于性能测试的第一印象：

性能 = sysbench
测试 = run
结果 = tps
数值要高大上

性能就是sysbench，而后测试就是跑一下，这就叫性能测试了，结果就是要TPS或者QPS，数值必定要高大上，这是你们对性能测试测试的第一印象也多是惟一的印象。咱们公司是属于乙方的技术服务提供商，咱们对业界的不少产品进行过性能测试，因此今天想为你们带来一些不太同样的故事，以及咱们在作性能测试的时候一些视角。

我今天大概会向你们介绍三件事情：

第一件事情是咱们观察到，你们在作性能测试的时候，在针对数据库的中间件作性能测试的时候会有一些常见的方法，咱们会介绍其中的三种方法和相关的场景以及可能产生的一些错误。

第二件事情是在性能测试中咱们在实际中使用了几年的一些方法，这些方法可能跟你们日常见的不太同样。

第三件事情是一个关于分布式事务相关的章节。

一．性能测试的常见的(错误)方法

首先看咱们的常见方法，其中我想讨论三件事情，

• 测试中间件性能的观测对象是中间件 ?
• 性能测试指标选取: 吞吐 or 延迟 ?
• 性能测试报告的结论 是要获得绝对数值 ?

1.测试中间件性能的观测对象是中间件 ?

咱们先关注咱们的观测对象是谁？咱们来看几个故事. 这张图是常见的一个中间件的形态，中间件和数据库是分别在两个操做系统中，操做系统分为用户态和内核态，流量从中间件过来，压力从网络流向数据库，而后数据库自己的压力会流向存储，这是大概的压力流向。

在这个压力流向图中，红色的箭头是你们作性能测试时的观察点，能够看到: 咱们在观察这个压力时, 观察的不是中间件的压力, 而是后面多个系统产生的一个综合的压力，在这种观测视角下咱们很难评估一个中间件究竟是好仍是很差。

| 测试中间件的观察对象是中间件+链接属性+?

这是一个真实的故事，有一天咱们的测试同事找到我，让我解释一下这个图是怎么来的？

如图所示，这个中间件是一个简单的流量转发类的中间件，后端只有一台数据库, 压力类型是Point-select，就是作简单的命中主键的select，而且压力是所有命中缓存的，能够验证数据库没有任何磁盘IO. 横轴是并发，纵轴是QPS，蓝色的这根线是中间件的性能线, 橙色的这根线是直连MySQL的性能线。

为何经过中间件的性能会比经过MySQL的性能要高？

当时拿到这个结果的时候，我去验证了全部的环境，我认为环境没有问题，压力没有问题，那么这多是我这一辈子中离诺贝尔奖最近的一次，若是说这个现象成了，那么就至关于我在这个网线造了一个黑洞出来，信息经过这根网线的速度比光速要快， 由于你们知道网线上跑的是电子, 电子的最高速度是光速，或者说我换用一根光纤, 它的最高速度也就是光速，咱们的数据库SQL跑的速度要比光速快，才能作出刚才的性能图。

固然最后我是没有拿到诺贝尔奖的，是由于链接MySQL 5.7时，直连数据库和链接中间件的两根链接的类型不一样，其中一端是默认开启的TLS的，直接用客户端去连数据库的时候默认会开启TLS，而链接中间件时则不通，由于通常的中间件实现都会比较懒，它不会去作TLS, 因此这两根链接的条件不对称，直接致使了中间件的性能要比直连数据库的性能要好。这是我想带来的第一个场景。

这个场景就扩大了咱们的观察对象，对中间件的性能测试，除了中间件之外还须要观察它的链接属性的不一样。

咱们来看一下第二个故事。你们来考虑一下这个SQL：

prepare ps from ‘…’;
select * from a limit 1;
select * from b limit 1;

若是我将这三句话发往一个中间件和发往一个数据库到底有什么区别？

中间件的状况如图所示，后面有两个数据库，将第一个prepare发往A库，而后第二个select可能发往任意一个库，咱们假设它发往A库, 那一切正常，若是第三个select发往了B库，那么prepare会被带到B库上去作。在目前的语句下, 其实prepare是能够不须要带到B库上的，由于它后面的select跟prepare没有关系. 但若是我下面发一个Exec, prepare就必定要带到B库上。

这个场景中, 发到中间件的压力和中间件实际下发到数据库的压力可能会变多，之因此变多, 是为了中间件要维持一个特性，这个特性叫中间件的上下文转移。你们若是用过开源的中间件，这个术语应该就比较熟悉。

| 中间件的上下文转移

· 事务级别 (同一事务必定发到同一节点)
· 会话级别 (上下文迁移)

• 系统变量
• Prepare Statement
• 临时表
• 用户变量
• 与会话相关的特殊函数
• LAST_INSERT_ID/ROW_COUNT
• Default schema

事务级别的上下文转移, 指的是对于简单转发类中间件, 同一个事务的SQL要发往同一个后端的数据库。

除了事务级别, 常见的中间件还会作一些会话级别的上下迁移，好比系统变量，若是把binlog关掉，意味着以后的语句不计入binlog，那么后面的语句无论发到哪台数据库必定要把这个系统变量带到后面的数据库里边去。而后好比说Default Schema，这个是常见的中间件须要实现的部分。

咱们来看后面，还有一些常见的中间件不必定会实现，好比会话级别的上下文迁移还包括prepare statement、临时表、用户变量以及特殊函数。特殊函数其实正常的状况下人为使用的并很少，可是你们使用的各个driver都会依赖于这些特殊函数来作，好比说分页、筛选都会依赖于这些特殊函数来作，因此一个好的中间件会对于这些绘画级别的，上下文转移的行为要么支持，要么有明确的文档说明不支持，要么加以限制，这个是中间件的上下文转移带来的在性能测试中的差异。

因此咱们再次修正咱们中间件的观察对象，中间件的观察对象是除了中间件，还有链接属性，还有必需要观察实际下发的SQL。

| 同一环境下, 中间件损耗越小是否QPS必定越高？

第三个故事，咱们来考虑一下，在同一个测试环境下，两款中间件中损耗比较小的那款是否是获得的QPS必定会更高？正常的状况下咱们认为一个系统里边若是某一个环节损耗小了，总体的损耗就小, 获得的延迟更低，QPS必定会更高。

但实际上, 请你们考虑这样一个场景，我列举了左右两款中间件，左边是损耗比较高的中间件，右边是损耗比较低的中间件，都用同一个压力测试场景，打了一百个并发下去。

左边的中间件由于它的损耗比较高， 至关于下发了20个并发，另外的80个并发在损耗的过程当中，右边的中间件稍微好一点，它下发到数据库的并发是60个并发，那么数据库在不一样的并发下，由于有资源竞争, 单线程的QPS就会变。20并发下竞争会比较低，因此每个线程，它的QPS比较高，多是100 QPS。而60并发下, 每一个线程的QPS可能只有30，20个并发乘以100个QPS和30个并发乘以60个QPS，算下来:损耗比较高的中间件，有可能它的QPS会更高。

这是性能测试中的一个常见错误，若是只是简单的观测，那么我选择的应该选那款比较慢的中间件。

这是个人第三个场景，日常咱们在实践的时候会去计算中间件的一个指标，咱们把它叫作穿透率，一个中间的穿透率是多少，这个意思是中间件往下发的压力 比 发到中间件的压力。

回到以前快慢中间件比较的场景，左边中间件的穿透率是20%，右边中间件的穿透率是60%。经过计算穿透率能够评估一个转发类中间件的性能。若是是分布式类的中间件还不能这样评估，由于穿透率越高，并不表明一个分布式的中间件的处理性能更好，须要其它的指标来评估。

咱们在测试的时候，若是要比较两个环境的性能，就必定须要注意: 先让对数据库的压力表现相同，其中就包括链接的属性、SQL、平均延迟等，才能比较两个中间件的性能的好坏。若是不知足这个条件，测出来的是整个系统的表现，而并非一个中间件的性能表现。

因此中间件的最终的测试对象，咱们最终的结论：

测试中间件的观察对象是
中间件+向数据库的实际压力

在这里我能够透露给你们一个小的故事，这个故事是真实发生过的，由于咱们是作乙方的，像大型的银行金融机构提供解决方案，而后有一次个人项目经理就来找我，说咱们中间件测试跟友商的比QPS差了不少。我说你给用户跪吧，以后咱们派了一个资深的工程师到现场去看，把两套环境拿到一块儿看，咱们发现友商的环境上，MySQL的binlog是关掉的。而后咱们就把那个项目经理从地上扶起来，向客户去解释其中的道理，咱们解释的道理就是刚才这个道理: 必定要观察数据库上的压力表现。

这是一个sysbench的性能报告，你们第一眼看这个报告, 关注的一般是这个位置，4000QPS，纯读的压力。

除了这个部分之外还须要注意其余两个部分：

第一，Response time, 即响应时间，下面的几个数值是最小值，平均值、最大值和95%分位数，这四个值能构造出一个延迟分布的密度曲线大概的形状。举个例子，若是在如今这个状况下，95%分位数接近最大值( 好比把图中的138.01ms改为438ms)，那么说明这个测试中的异常值的出现几率超过5%，好比说，能观测的性能点是12万个点，在这12万个点里边有超太高过5%的观测点，是高过438毫秒的，那么咱们认为: 在这个压力表现下, 这个中间件的某一些链接的延迟颇有可能出现了异常. 响应时间指标的做用，是构造延迟的分布曲线的大概形状。

第二，Threads fairness，线程的公平性，举例两款中间件，有一款中间件咱们打4个并发下去，其中三根链接是不工做的，只有一根链接效率特别高，它能够达到4000 QPS；另一款中间件每根链接效率没有那么高，可是每根链接均可以达到1000 QPS。若是你们去买的话，用一万块钱去买中间件，你们会买哪一款. 这就是线程的公平性的度量目的。线程的公平性的两个数值: 前面是它的平均数，后面是它的标准差。这个标准差必定不能过高，若是过高的话就意味着它每根的线程处理的效率不同，通常意味着这个中间件中间哪一个环节错了。

2.性能测试指标选取: 吞吐 or 延迟 ?

高压力下, 高吞吐
低压力下, 低延迟

举例，若是有一款中间件在低并发的状况下延迟很低吞吐还好，随着它的并发愈来愈高，它的吞吐基本上是一个线性的增加，并发数增加十倍，吞吐量增加了九倍，这个系统已经看起来还不错，可是延迟增加了20倍左右，这一款中间件你们在实际的业务上会不会选呢？

我咨询过业务相关的同行，他们的答案是彻底不同的，有人会用，有的人不会用，彻底取决于它的业务类型。 若是是个低并发的业务，会认为这个中间件够用，若是说业务是一个高并发而且对延迟没有过高的要求，150毫秒以内的延迟都能接受，那么这款中间件它的吞吐量线性成长率实际上是很是不错的。但若是是延迟敏感型的业务，它的延迟要求很高，好比说它最多只能接受25毫秒的延迟, 那么这款中间件就不该该选。

因此在进行性能测试时，到底选择吞吐仍是选择延迟是要跟着业务走的，业务必需要给出底线咱们才知道怎么测，不然拿到例子中的数值，第一反映就是一百毫秒这个数很大，就不想用，但其实它的吞吐的线性成长率仍是比较好的。

通常的来讲，开发在作一个系统的时候很容易低成本的作出高压力下能承受高吞吐、低压力下能作到低延迟的这样一个系统，可是反过来不行。若是在高压力下作低延迟，这个成本在开发上是异常的高，须要用尽各类极端的技术来作，若是在低压力下作高吞吐，这个在现实中没有意义，因此在成本受控的状况下作出来的通常都是这样的效果. 若是你们从事中间件的测试的话，那么对中间件的期待的要求不要过高，贴合业务的性能表现是最合适的。

这是我想讨论的第二件事情，性能指标的选取就是不一样的压力下必定要选取不一样的指标而且必定要贴着业务走，业务必定要告诉你它的底线在哪里。

3.性能测试报告的结论是获得绝对数值 ?

假设你们在评估这样一个数据库，这个数据库它的测试参数都列在屏幕上，测试使用sysbench工具，压力类型是OLTP只读方式，读的类型是点选，一共八张表，每张表有一兆行的数据，使用Socket链接，64并发，测试环境是72核超线程. 在这种状况下这台数据库能作到QPS是40万以上，你们以为这款数据库怎么样？

若是你手里有钱，会不会去买这样一款数据库来支撑你的线上业务，这款数据库是谁？这款数据是MySQL 5.5。

这张图来自于MySQL 5.7的官方报告，其中这个点是MySQL 5.5，它能在64并发下作到40万QPS，看到这个数据时我其实有点惊讶， MySQL 5.5是我刚工做的时候的数据库版本，那款是你们公认的性能比较差的数据库，可是它就能作到40万QPS。

这张图来自于MySQL的一份报告，我强烈推荐这个报告的缘由是，首先这个报告里边是有绝对的数值，同时，报告里有对数值的比较，再同时它有对每一个场景进行压力分析和瓶颈分析。若是你们必定须要一份带绝对值的测试报告，我强烈推荐这份测试报告，由于它里面带了若干的分析，并且它里边有一句很是有意思的话：

Numbers are just reflecting what is behind。

这份报告有专门的一节来解释为何应该相信压力分析和瓶颈分析，而不该该相信绝对数值。咱们回到刚才这张图，MySQL 5.7在这个压力场景下能作到的是一百万，若是在128并发，按照最高到256的并发这样的场景下能作到1.6兆的QPS，但实际上咱们不多有人在线上能跑出这样的值. 按照咱们团队的多年测试的实践经验，作性能测试不要以找到值为目的，而要以找到瓶颈为目的，而且要把这个瓶颈解决掉。如此循环直到这个瓶颈没法解决为止。

实践经验:

以找到瓶颈为目的, 直到瓶颈没法解决
更容易找到 可重现的 正确的 性能值

好比说遇到操做系统的瓶颈，万兆网卡已经不够用了，吞吐已经上不去了，在成本内能买到的卡就是这个样子，那这个瓶颈就没有办法再解决了。这样咱们能获得一个正确的而且能够重现的性能值.

以上三点总结：

1.测试中间件的观察对象是：
中间件+向数据库的实际压力

2.性能测试指标选取:
在不一样并发下, 选择不一样指标

3.性能测试报告的结论应当是:
同等条件下的 性能比较 和 性能瓶颈分析

二．性能测试的一些(咱们用的)方法 * 2

下面介绍2种咱们用下来比较成熟的方法：

1.观测, 观测, 观测
-eBPF/Systemtap
-中间件自身提供观测
-USE
2.测试工具校准

关于观测：

第一，推荐两种观测工具，eBPF或Systemtap；

第二，咱们本身也作中间件，咱们中间件自身是提供了一些观测指标的，向你们介绍一下这种方法；

第三，有一种线程是对于资源消耗的观察手段，即USE；

| eBPF 操做系统级的观测

eBPF此处引用个人同事洪斌在今年的PHPCON的演讲，他的演讲主题是《MySQL性能诊断与实践》，其中详细的介绍了一下这个工具能给你们带来什么好处，列举其中几个，如：

1. 延迟分布，好比MySQL请求的延迟，VFS延迟，Ext4的延迟，块设备的延迟等；
2. MySQL的文件IO压力分析；
3. 临时表的生命周；
4. 短链接的分析；

详细演讲内容：github.com/actiontech/slides

举一个例子，下图是eBPF的一个脚本，可观察MySQL的延迟，它会给你们列出延迟的分布曲线:

左边这一类是延迟，从零到一，二到三，四到七，它是指数级增加，单位是微秒，能够看到的是 压力打在数据库上的平均延迟，大量的数据压力在128微妙到255微妙之间，这个数据库的总体延迟仍是不错的。

这张材料引用自Breddan Gregg的项目BCC，是eBPF的实用脚本集，它能观测操做系统的方方面面，来帮助你们作压力观测。

| 中间件自身提供观测

操做系统的观测已经很全了，为何中间件自己也要提供一些观测点，咱们本身的中间件DBLE，是一个开源项目，GitHub上能够搜到，在DBLE中咱们提供了这样的一种观测方法，以下：

DBLE把一个压力下来分红了六个阶段：

- 开始梳理
- 完成解析
- 完成路由分配
- 从数据库回收结果
- 后置处理
- 反馈处理

每一个阶段提供了时间分布，这样咱们可知道压力到底在中间件的哪个阶段变慢。

好比在这个数据下，中间件的性能其实不错，是由于从第三个点到第四个点之间是后端数据库的处理，它占了整个处理时间的70%以上，因此在这种状况下能够判断后端数据库已经慢了，而不是中间件产生了什么太大的问题，因此中间件自己应该提供观测。

在这个项目的文档中, 咱们把画了中间件的压力处理流程，其实对于大部分的中间件都是这样的，这张图在DBLE开源的文档上均可以找到。安利一下咱们本身的中间件DBLE，你们有兴趣的话能够去看一下，文档齐全，分析方法也很齐全。

中间件自己的观测与操做系统的区别在于: 中间件提供的视角是站在压力处理的视角来提供的，操做系统视角是站在资源的视角来提供，这两个视角缺一不可。若是只知道操做系统说IO压力大，可是并不知道是哪一个环节形成的压力大，那诊断瓶颈的成本会比较高. 这就是为何中间件要补充一个视角。

| USE

对于资源来讲，强烈推荐《性能之巅》这本书，它介绍的分析方法叫USE，就是使用率、饱和度、错误率这三个指标就足以评估一个资源，IO资源也好，网络资源也好，足以评估一个资源如今的使用情况。

举一个例子，为何使用率和饱和度得分开，若是如今操做系统告诉咱们内存占用率是100%，内存能不能再申请出来一块？是能够的，由于内存的使用率100%，其中好比说有50%是分给buffer和cache, 操做系统会自动回收，这种状况下内存的使用率是100%，但饱和度并无达到饱和，咱们能够继续使用内存，直到它的饱和度上升到100%为止，这个内存就再也申请不出来了。

因此这就是为何这本书将使用率和饱和度必定要拆开的缘由。强烈推荐！

咱们在DBLE中间件内部也提供了相似这样的观察机制，有点像Linux的Load average. 咱们对于它的每个线程的使用都提供了一分钟、五分钟或者是十五分钟这三种使用率的评估。经过使用率就能够观察到在并发压力下中间件的运行情况究竟是死在了一根线程上，仍是每根线程上承载的压力差很少。以前关于线程公平性的问题也能够经过这个指标来诊断。

2.测试工具校准

测试工具校准，举个例子，BenchmarkSQL，是Java版的TPCC，很多银行都在用它检验一个数据库或者是检验一个中间件能不能正常表现，可是咱们碰到了这样一个问题：在测试压力中, 测试脚本要删一个记录，若是删不掉我就一直的删，一直删，可是这个工具在RR的隔离级别下形成一个死循环。

这个死循环是这样的：

第一句话它把auto commit设成0；

第二句select就会开启一个事务；

第三句话在这个压力下跑过一段逻辑以后再select看看这行数据还在不在，若是在就去删掉它。若是隔离级别是RR的，在第二三句之间把这行数据删掉，那么此时还能看到这行数据对吧. 但以后的delete回应没有影响数据行，因此BenchmarkSQL就会陷入上面的这条死循环，看到数据, 删除, 没删掉, 而后就一直会去删，可是一直能看到这行数据，因此就会陷入这个死循环。

换句话说BenchmarkSQL，在RR的隔离级别下就会形成这样一个死循环。 很难想象这个工具是在银行客户中被大量使用. 有一天项目经理告诉我，友商的中间件好着啊，而后咱们就必需要去研究这款中间件，为何它没有问题，缘由是设置了RR的隔离级别, 它实际下到数据库的压力是RC隔离级别，RC隔离级别错在第三步看不到这条数据，它就不会跑下面这个循环，因此人家的中间件的错误将测试工具的错误抵消了。咱们呼吁在测试时保持科学的态度.

在开始演讲以前姜老师的笔记本在这个环境下工做是好的，我说能不能换个人笔记本作这个演讲，我就把线插入个人笔记本而后两边都显示不出来了. 这个时候姜老师最应该说的一句话是什么呢？在个人环境下它是好的啊，但他并无说，这是一个很科学的态度。

关于性能测试，咱们推荐两个方法：

第一个方法，性能测试必定要去观测，观测的目的是什么，看到瓶颈，看到瓶颈的目的是什么？解决掉它以得到一个彻底能够重复的正确的性能测试值来得到正确的结论。

第二个方法，测试工具必定要校准，业界经常使用的测试工具备不少，不要相信一些小众的测试工具，每一种测试工具都必定要校准。校准的话能够用多种测试工具同时去跑，去校准，或者是去分析测试工具的压力类型，刚才的观测过程就足以分析一个测试工具实际下发到后端的压力究竟是什么，足以看到它的压力类型是什么，分析它的压力模式是否是正确的，以作测试工具校准。

因此在咱们的公司ISO流程里边有一个规定是半年用这个测试工具作一次校准，由于测试工具也在面临着升级，咱们面临的测试工具不少，这是我想讨论的第二个部分。

三．分布式事务相关*1

分布式事务相关，其实跟性能没有什么太大的关系，它来自于一个故事。咱们作数据库的服务提供商，面试过不少人，你们都会在分布式事务上企图寻找亮点，而后咱们就常常问如何证实分布式事务是有效的，好比说MySQL有XA，以前也有公司推出了快照隔离级别的分布式事务中间件，如何测试分布式事务中间件是有效的，咱们获得最多的一句话就是你能够随便的拔电源一百次，而后那边就说能够拔两百次，那边又说能够拔三百次，都是这样的一个状况。

1. 事务性

对于分布式事务相关来讲，无论是正确性也好仍是性能也好，首先是要去验证ACID数据的异常，由于你们作数据库都会妥协，说这个数据库比那个数据库性能好必定是作了什么妥协的，这些技术必定是关系到这些数据异常。

| ACID相关的数据异常

数据库异常的分类：

脏读/不可重复读/幻读/脏写/更新丢失/写偏序/读偏序/…

测试分布式事务时, 至少应该知道这些数据异常的场景. 一个分布式事务实现，若是脱离MySQL在中间件上作一个分布式事务实现的话，必定是从头开始作东西，就必定要从最原始的理论基础来去证实每一个异常场景都能被正确处理。

| 针对锁机制的弱点: S2PL/SS2PL

大量的分布式事务实践在使用锁机制，那么在锁机制里边就两种锁一种是S级别的2PL和SS级别的2PL两种，每一种实现都有它的弱点，建议针对这些弱点进行相关的正确性和性能测试。

2.可靠性和性能

• CPU
• 内存 (perf - NUMA)
• 磁盘 (systemtap - 延迟/错误)
• 网络 (tc - 延迟/乱序/篡改/丢失)
• 进程 (kill / hang / 线程乱序执行)

…

关于破坏性测试，拔电源到底够不够？可靠性能的测试必定要从这几个方面，必定先从资源的角度去考虑。

第一，内存， NUMA到底该不应关闭，把它打开对性能到底有什么影响，均可以经过perf来观察到，或者是经过perf来注入一些错误点让它产生一些错误，内存或CPU均可以注入错误。

第二， 磁盘很早的时候淘宝的团队就在用systemtap在IO上作延迟和错误的注入，好比模拟一个IO是失败的，或者是模拟一个IO无限的等待下去，Pingcap也有相关的文章介绍，这也是咱们的平常使用的技术。

第三， 网络，用TC能够作出四种网络故障，延迟，乱序，丢失，篡改. 网络故障不单纯是开启iptables， tc能够作出这四种，而且按几率来安排这四种故障。

第四，进程，关掉电源不少时候模拟的都是进程kill. 除了这个之外还有进程hang，以及不少人都会忽略掉的线程乱序执行。在某些机器中，程序的线程是按照某种顺序执行的，可是换一个CPU或者换一个环境，或者是打个干扰压力上去, 程序的线程就会乱序执行。

咱们看一个分布式事务测试报告说测试对象是正确的，必定要考虑这些方面. 下面是咱们同事写的一句话：

怀着敬畏之心
怀疑每一行代码都会
-出错
或者
-不返回结果

必定要怀着一个敬畏的心怀疑每一行代码都会出错或者是不返回，我写这个slide的时候应该是三四周以前，后来第二周阿里就挂了，而后阿里的故障分析报告上也是一样的一句话，就是你必定要怀着一个敬畏之心. 你们经过这么多钱买下来的经验都是这样的，对于一个系统必定要怀着敬畏之心去看待它，不要没事儿去拔电源， 我又不是卖电源的对吧！

以上是我今天的分享，谢谢你们！

PPT下载连接：
https://github.com/actiontech...