mysql中间件php不太一样的角度和你分享MySQL中央件机能测试爱可生

择要：我本日代表我的团队向大家来先容一下MySQL中间件性能的测试，为大家带来一些不太一样的故事，包括我们在做性能测试的时候一些不太一样的视角。

分享大纲：

1.性能测试的常见的(缺点)方法 3

2.性能测试的一些(我们用的)方法 2

3.分布式事务干系 1

我本日代表我的团队向大家来先容一下MySQL中间件性能的测试，之以是讲选这个主题是由于我把稳到大家都是高等的DBA，我们也有很多的高等的DBA，跟大家谈天的时候都会把稳到，大家对付性能测试的第一印象：

性能 = sysbench

测试 = run

结果 = tps

数值要高大上

性能便是sysbench，然后测试便是跑一下，这就叫性能测试了，结果便是要TPS或者QPS，数值一定要高大上，这是大家对性能测试测试的第一印象也可能是唯一的印象。
我们公司是属于乙方的技能做事供应商，我们对业界的很多产品进行过性能测试，以是本日想为大家带来一些不太一样的故事，以及我们在做性能测试的时候一些视角。

我本日大概会向大家先容三件事情：

第一件事情是我们不雅观察到，大家在做性能测试的时候，在针对数据库的中间件做性能测试的时候会有一些常见的方法，我们会先容个中的三种方法和干系的场景以及可能产生的一些缺点。

第二件事情是在性能测试中我们在实际中利用了几年的一些方法，这些方法可能跟大家平常见的不太一样。

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

一．性能测试的常见的(缺点)方法

首先看我们的常见方法，个中我想谈论三件事情，

1.测试中间件性能的不雅观测工具是中间件 ?

我们先关注我们的不雅观测工具是谁？我们来看几个故事. 这张图是常见的一个中间件的形态，中间件和数据库是分别在两个操作系统中，操作系统分为用户态和内核态，流量从中间件过来，压力从网络流向数据库，然后数据库本身的压力会流向存储，这是大概的压力流向。

在这个压力流向图中，赤色的箭头是大家做性能测试时的不雅观察点，可以看到: 我们在不雅观察这个压力时, 不雅观察的不是中间件的压力, 而是后面多个别系产生的一个综合的压力，在这种不雅观测视角下我们很难评估一个中间件到底是好还是不好。

l 测试中间件的不雅观察工具是中间件+连接属性+?

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

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

为什么通过中间件的性能会比通过MySQL的性能要高？

当时拿到这个结果的时候，我去验证了所有的环境，我认为环境没有问题，压力没有问题，那么这可能是我这生平中离诺贝尔奖最近的一次，如果说这个征象成了，那么就相称于我在这个网线造了一个黑洞出来，信息通过这根网线的速率比光速要快， 由于大家知道网线上跑的是电子, 电子的最高速率是光速，或者说我换用一根光纤, 它的最高速率也便是光速，我们的数据库SQL跑的速率要比光速快，才能做出刚才的性能图。

当然末了我是没有拿到诺贝尔奖的，是由于连接MySQL 5.7时，直连数据库和连接中间件的两根连接的类型不同，个中一端是默认开启的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库上。

这个场景中, 发到中间件的压力和中间件实际下发到数据库的压力可能会变多，之以是变多, 是为了中间件要坚持一个特性，这个特性叫中间件的高下文转移。
大家如果用过开源的中间件，这个术语该当就比较熟习。

l 中间件的高下文转移

· 事务级别 (同一事务一定发到同一节点)

· 会话级别 (高下文迁移)

- 系统变量

- Prepare Statement

- 临时表

- 用户变量

- 与会话干系的分外函数- LAST_INSERT_ID/ROW_COUNT

- Default schema

事务级别的高下文转移, 指的是对付大略转发类中间件, 同一个事务的SQL要发往同一个后真个数据库。

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

我们来看后面，还有一些常见的中间件不一定会实现，比如会话级别的高下文迁移还包括prepare statement、临时表、用户变量以及分外函数。
分外函数实在正常的情形下人为利用的并不多，但是大家利用的各个driver都会依赖于这些分外函数来做，比如说分页、筛选都会依赖于这些分外函数来做，以是一个好的中间件会对付这些绘画级别的，高下文转移的行为要么支持，要么有明确的文档解释不支持，要么加以限定，这个是中间件的高下文转移带来的在性能测试中的差别。

以是我们再次改动我们中间件的不雅观察工具，中间件的不雅观察工具是除了中间件，还有连接属性，还有必须要不雅观察实际下发的SQL。

l 同一环境下, 中间件损耗越小是否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；

l eBPF 操作系统级的不雅观测

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

1. 延迟分布，比如MySQL要求的延迟，VFS延迟，Ext4的延迟，块设备的延迟等；

2. MySQL的文件IO压力剖析；

3. 临时表的生命周；

4. 短连接的剖析；

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

左边这一类是延迟，从零到一，二到三，四到七，它是指数级增长，单位是微秒，可以看到的是 压力打在数据库上的均匀延迟，大量的数据压力在128奇妙到255奇妙之间，这个数据库的整体延迟还是不错的。

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

l 中间件自身供应不雅观测

操作系统的不雅观测已经很全了，为什么中间件本身也要供应一些不雅观测点，我们自己的中间件DBLE，是一个开源项目，GitHub上可以搜到，在DBLE中我们供应了这样的一种不雅观测方法，如下：

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

- 开始梳理

- 完成解析

- 完成路由分配

- 从数据库回收结果

- 后置处理

- 反馈处理

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

比如在这个数据下，中间件的性能实在不错，是由于从第三个点到第四个点之间是后端数据库的处理，它占了全体处理韶光的70%以上，以是在这种情形下可以判断后端数据库已经慢了，而不是中间件产生了什么太大的问题，以是中间件本身该当供应不雅观测。

在这个项目的文档中, 我们把画了中间件的压力处理流程，实在对付大部分的中间件都是这样的，这张图在DBLE开源的文档上都可以找到。
安利一下我们自己的中间件DBLE，大家有兴趣的话可以去看一下，文档完好，剖析方法也很完好。

中间件本身的不雅观测与操作系统的差异在于: 中间件供应的视角是站在压力处理的视角来供应的，操作系统视角是站在资源的视角来供应，这两个视角缺一不可。
如果只知道操作系统说IO压力大，但是并不知道是哪个环节造成的压力大，那诊断瓶颈的本钱会比较高. 这便是为什么中间件要补充一个视角。

l 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数据的非常，由于大家做数据库都会妥协，说这个数据库比那个数据库性能好一定是做了什么妥协的，这些技能一定是关系到这些数据非常。

l ACID干系的数据非常

数据库非常的分类：

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

测试分布式事务时, 至少该当知道这些数据非常的场景. 一个分布式事务实现，如果分开MySQL在中间件上做一个分布式事务实现的话，一定是从头开始做东西，就一定要从最原始的理论根本来去证明每个非常场景都能被精确处理。

l 针对锁机制的弱点: 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的时候该当是三四周之前，后来第二周阿里就挂了，然后阿里的故障剖析报告上也是同样的一句话，便是你一定要怀着一个敬畏之心. 大家通过这么多钱买下来的履历都是这样的，对付一个别系一定要怀着敬畏之心去看待它，不要没事儿去拔电源， 我又不是卖电源的对吧！

以上。