文人相轻

在上一任技术员神奇地离职后，费劲了千辛万苦，朋友招来了一个新的技术员。
然后这天，朋友跟我说……

嗯，大概如此。文人相轻吧，大多数程序员看别人的代码都是狗屎。以前我看很多人的代码也觉得是狗屎，是狗屎的原因是看不懂。当然以前的我看现在写的代码应该也是狗屎，就像我现在看以前写的代码也都是狗屎一样。
我翻很久以前自己写的代码的时候，心里想的最多的就是，“这以前是哪个傻逼写的狗屁代码。”  

当然了，这种心理活动一般不会说出来。
好嘛，说出来了……

苦逼的面试

自从上任技术员卸任后朋友就走上了漫漫招聘之路。
不是，应该说在他卸任之前就已经在招募人手了，因为他感觉人手不够用。
可惜……

这年头外面的人鱼龙混杂，23333……
在这之后，朋友始终处于病急乱投医的状态。比如。

还有……

朋友之所以惦记着Redis，是因为之前我跟他有提起过用Redis提高性能……
说到这里我发现他对我说的话还是满上心的，就是我打码打得手有点疼。

购物车？会话车

在这之后的两个多星期里，朋友陪着那个新来的技术员一起加班，好像是折腾购物车之类的东东，大概意思就是在买票的时候顺便能一起把购物车里的东西结算一下，然后有了购物车之后倘若他们会善于利用购物车减缓数据库提交，那当然是极好的。
他们在折腾这些东西，我懒得去管，也就一点没过问。至于他们把购物车内容全扔Session里了，我也没啥意见。

其实我觉得有这时间，应该进一步修改系统的，把那些该静态化的东西静态化，该加缓存的东西加一下缓存。

说到这里，不得不提到之前的技术员搞的订单提交。当时搞的订单提交是这样的，就是当来一个订单提交请求后，开启一个数据库事务，直接扣库存，如果扣除失败了，那就是卖光了。
在说到这里的时候，我还被那个技术员教育了一下。原话如是说，数据库中的库存字段设计为UNSIGNED INT，也就无法小于0了，因此当库存没有的时候，就会失败，不会超卖。
然后他颇为得意地说，技巧。

后来我测试了一下，的确当数据等于0的时候执行语句会报错，也就没再去追究了，虽然总觉得抢购项目里几秒内提交几百个订单全都扔到数据库这边排队是对数据库的不尊重……

大概两周后，那边有消息了，大概就是功能基本完成准备上线了。时值正准备第四波高峰。

加速乐的坑：始终200

用加速乐的免费CDN服务了。就在高峰到来前的几天，朋友找到我，说准备卖了，让我给压测一下看看系统是不是有问题。
然后他问了我一个问题，说点击购票后在弹出层里，如果要返回的话，点取消是可以的，但是点浏览器的后退不行，会回退到登录页，为啥。
这是一个经典的动态操作问题其实。不过轮不到我回答他这个问题，就发现了更多的问题，多到后来我忘记了这个问题……

首先遇到的就是加速乐这个免费的CDN的问题。
问题的起因是我在刷新测试的时候，发现首页的背景图每次都要很久才能完整显示。而我看了一下开发人员工具的网络嗅探设置，确认没有禁用缓存。

然后仔细看这张图。返回的状态码是200不是304，说明服务器完整返回了所有的数据。而请求头中包含了 If-Modified-Since以及If-None-Match，说明浏览器本地有缓存，并且正确提交了验证数据。
关键点来了。
服务器的返回中，Last-Modified以及Etag与请求头信息完全匹配，这时候服务器应该返回304表明没有修改才对，但是！加速乐的服务器却返回了200，把整个文件全部重新传输了一遍。X-Cache为hit表明这是CDN的响应，命中了CDN的缓存。
测试了很多遍后，赫然发现加速乐的CDN几乎不会返回304。只有当个别时候X-Cache为miss的时候，也就是CDN缓存未命中的情况下，才会返回304，这是源服务器返回的。
这样的话CDN的效率该有多低？怪不得我总觉得有加速乐这个CDN还不如没有快。

与此同时，这背景图高达几百K，确实有点大。于是我跟朋友反馈了两个意见，一个是图太大了，压缩下；再一个就是加速乐的响应总是200没有304，似乎有点问题，查查是不是加速乐的设置有问题，必要的话去咨询一下加速乐的客服。

过了一会儿，朋友给我反馈回来加速乐的客服是这么回复的。

加速乐前身是百度的，而百度所有的客服都是这个尿性，我深有体会，那就是他们都很忙，经常说话说着说着就没声儿了。
总之百度这些玩意儿都不靠谱，以后能不碰尽量不要碰。
看到这里的时候我突然想起来，我的网站也用了加速乐，难道也这样。
于是我先去百度的网站上看了下，确认不是自己知道的HTTP协议有问题。

然后我就去自己的网站上看了下。

尼玛。果然也是完全一样的情况。缓存标记都匹配的时候，CDN依然返回200，然后完整的内容。

最后我不甘心，直接改本地hosts解析，绕过了加速乐的CDN。

……这说明什么？说明有CDN还不如没有。
于是我决定自己去找百度加速乐的工作人员问一下情况。

然后我就去找百度加速乐的客服了。之前因为他们的节点出问题导致访问故障的时候找过，所以还在我的好友列表里。
然后我惊奇地发现他们居然一模一样的回复。

就是这样，说着说着突然给我换了一个人。
然后……就再也没有回复了。

后来我也懒得去理了。
反正我在之前很多次事情中已经知道了百度的客服基本上都是这个尿性，说着说着人就不见了，问题也没解决，好像都很忙的样子……

后来我的措施就是，取消了主站在百度加速乐上的CDN加速。后面有时间衡量一下后看看是不是彻底取消他们的CDN。

不过话说回来，难道这是因为我自己不懂？反正结果就是这样了。
不过虽然我能给自己的网站取消CDN，朋友的却不能取消，因为他还需要靠CDN来隐藏网站IP防范攻击。所以除非换CDN供应商，否则问题好像无解了。
但是换CDN供应商存在着未知的风险和因素，而且马上要使用的系统，好像有点太过于仓促。总之，最终就搁下了这个问题，其实是被阿里云的问题掩盖过去了。

阿里云神坑再现：这次是解决不了的坑了，且伴攻击和漏洞而来

最终所有事儿都掉链子了。

首先就是阿里云出现了神坑。
而这件事儿，到现在为止，我都无力吐槽，而且阿里云方面也完全拿不出解决方案。

事情的发现，要把时间点挪到加速乐之后，在加速乐的问题无解后，我照例对系统用ab进行了简单的压力测试。但是，问题马上发现。

这话我说错了，测完才知道，不是没多大变化，而是变化，相当大……
第二天，也就是上面说的卖票的日子到了。朋友找我帮忙做压测。
不过在测之前我还吐槽了一下加速乐，可见我完全没意识到真正的危机在后面。

首先就是。

注意我的用词，低到令人发指。
具体怎么令人发指的？看大图。

看到了吗？不到37次每秒，这性能比最开始的50来次都要低得多。
一开始的时候我被这个性能震惊了，怎么会低成这样，我知道你们改系统流程了，可是再大的改动再烂的水平也不至于把性能搞成这样吧，这特么还是两台机器负载均衡出来的结果，你们是在跟我开玩笑吗，就这性能还要去抢购？！
想到这里，我觉得要先冷静一下找原因，于是我先喝了一杯咖啡压压惊。

我说的重传是指TCP数据，上次的ECN事件后，服务器上都还装着Wireshark。

后来我为了搞清楚是PHP的问题还是网络的问题，改用ab压测一个纯静态页面。

你以为我会告诉你这是内网互联的测试数据吗？？

然后我在对应的机器上本地测试了一下。

说明问题完全不在网站本身。

Wireshark的监控出了很多类似下面的数据，我完全有理由相信这是网络层出了问题。

与此同时，我另外请教了技术群里的一些同学，他们也都给出了差不多的看法，觉得是内网的路由出了问题。

经过上次ECN一役，阿里云那边首先觉得就是ECN出了问题。

但是很可惜，这次不是，因为从服务器的一开始就关闭了ECN。
就这样，与此同时，网站还在遭受着CC攻击，朋友为此只能选择启用加速乐的高级防护。

就在这时，有人给朋友反馈了网站的漏洞，指出可以在未起售的时候手动猜测目标页面地址然后进入，可以实现提前购票。

这个漏洞很显然是因为对应的页面没有对当前时间做任何校验。我看了一眼代码，确实如此。但眼下根本没功夫去鸟这事儿。然而那个新来的技术小伙子激情四射，偷偷去改了，这为晚上的崩溃埋下了一枚无比精准的地雷……这是我后来才知道的。

眼看着就到卖票的时间点了，阿里云的网络问题完全没有回音，漏洞加攻击，此刻加速乐的高级CC防护也来掺一脚，所有的静态资源绝大多数返回了521这样一个浪漫的错误。

不得已关闭了加速乐的CC高级防护，过了一会儿，页面恢复了。

就在此时，新的问题又再次发现，那就是：一张票没卖出去。
虽然网站表现得很艰难，被各种问题蹂躏地死去活来，但还不至于一张票都没卖出去吧？那这每秒一千多的并发请求都在做什么？
很快地我赶紧用测试账号测试了一下流程，才发现问题：特么根本下不了单！
在下午阿里云和攻击以及漏洞种种事情之后，所有人都忘记了去测试整个流程是不是走得通。

怎么办？赶紧去查！
新来的小伙子被朋友骂去查代码。
与此，我用着自己极烂的PHP代码水平直接在线上查原因，终于……

看到了吧，什么叫坑？就是本地改了没有测试直接丢线上，还特么的没有备份！  
想骂都找不到词了，少壮不努力，老大想骂人都没词儿。

此时过售票点儿已经快一个小时了，在这种情况下，我只能给出最靠谱的建议就是。

而此时，心急的朋友已经另辟蹊径：直接把服务器回滚到前一天的节点了。

与此同时，那个新来的技术员也找到错误的原因了。

不过这错误真是让我好想骂人啊。

与此同时，虽然服务器被回滚了，但事情变得诡异了起来，那就是PHP页面执行速度开始变得异常缓慢。

与此同时，还有更严重的问题，就是数据库结构被更新了，和现有的程序完全不匹配。

一个问题没有解决，另一个问题出现，完全是无脑的节奏，根本没有时间去解决。
在此情况之下，朋友也只能无奈同意了推迟一两天再卖票。

这个新来的技术员被骂死了，然后给骂哭了，主动辞职不要工资了。这事儿我才知道丫居然是95后的小家伙。哎，比我小那么多……好忧桑。
但出于怜悯之心，我就劝朋友还是好好教育一下就好，毕竟态度不错，虽然经验欠缺。

有时间跟阿里云割据了

上次说到，给阿里云提交了工单。
而阿里云方面当天给出的回复是，高峰期网站监控到流量达到数十M，证明压力是可以打上去的，建议查查网站程序的问题。

我之所以说40M都是静态资源，是因为静态资源用不到内网互联，应该不会有太大影响。
后来我熬夜不写代码去测试阿里云的服务器，为了朋友这么牺牲自己的时间我都被自己感动了。
感觉有点奇怪，新建了一个最简单的无内容的纯静态页，居然都性能奇低，本机测试却又是好的。

具体测试结果是这样的。本机测试是这个结果。

但是内网同样的压测参数，却是这样。

阿里云给出的回复。

好嘛，乃们工程师下班了，我还在苦逼地给你们测试。

后来我熬夜做了更加详细的测试，感觉阿里云这个网络真不是一般的奇怪。
参见下面三个结果。

新建一个目标服务器上的空网站，端口100，内容啥都没有，就只有一个静态页面。
然后在本机用ab测试，并发数从100到500，结果如下。

可见基本上没有太大变化，维持在3400-3500RPS左右。

然后换另外两台服务器用ab通过内网IP去压测。

从图中可以看出，趋势大致相同，在并发数225以及以下的时候，性能尚可（至少没惨不忍睹），但是在225以上，性能跌成了梯状。

第二个我通过朋友把这个结果反馈给了阿里云，大概他们也觉得问题有点麻烦，然后再加上朋友电话敦促他们必须解决因为隔天又要买票，于是他们用电话联系了我，最终加了旺旺来解决这个问题。

在解决问题的一开始，我就有点抓狂。因为他们在ab这个工具上拧巴了。
大概是朋友作为客户，给他们传递的信息不是很准确，因为朋友给他们说的是自己的网站业务速度非常慢，并且查了下不是应用自己的问题，要求他们解决。于是他们就无视了ab这个工具，觉得这个工具测出来的不是准确的数据，还是先来压测业务本身。
我跟他反复强调静态文件都那么烂了还测什么业务，然后他跟我杠上了。
最后我差点要骂人了，终于我说，你别管客户怎么跟你说的他啥都不懂，你以我说的为准，你只需要帮我解决静态文件的问题就行了，业务上的事儿我自己会解决。  
然后他问我是不是确定这样可以，我说没问题，他说那好吧。
于是互相加了旺旺来解决这个问题。

他一上来就用Linux使用公网IP按照我给的命令行压测目标机器。

……668RPS。吓尿了。为啥公网会比内网还快？
我以为在这时间差中问题无声无息地解决了。
可是内网重复测了一下，我确定问题还是有。

然后我就郁闷了。

于是我的人生观要被改写了，难道是Server2012到Server2012有问题……

想到这里，我决定改用Server2008做客户端试试，后来证明这个完全没有改善，依然是那个蛋德行。

这时他提出了一个方案，就是他找一个机器临时部署一个nginx，然后从这边访问过去压测。

他本机测了一下，是这个结果，证明服务器没问题。

但是到我这边，用Server2012去访问后，就变成了这个蛋德行。

36！36！36！蛋疼的事情要说三遍。
到这里，我的精神几乎处于崩溃边缘，难道选择Server2012是个错误……
于是我果断换了一台Server2008R2测试。
好吧依然是这个德行。

这时候，他开始打ab的主意了……他觉得我用的ab有问题……因为他用Linux压过来可以，那就不是网络有问题…….

然而我已经抓狂了……你说jmeter就jmeter吧，随便你折腾。
你说Linux下是5700还是7000纠结这个有意思吗。。

我发誓我当时真想把鞋砸他脸上，如果能砸得到的话，因为为了配合他的测试，我都已经把其中一台服务器重置为全新的服务器了。

在这之后，大概他觉得确实有点问题，就自己在另外一个区搞了两台Server2012测试，好像也是一样的情况，然后就交给后端去查了，让等待……哦呵呵，能等出啥结果，后面会看到，不过几天内是不会看到有回应是妥妥的了。

为了这事儿已经把服务器全部换了一拨了。
现在咋办？

简单，继续掉链子！

阿里云的问题暂时搁浅，但至少不是完全不能用。第二天朋友又飞另外一边，下午委托我监控一下服务器，晚上卖票。
虽然网站网络有问题，但好在前一天测试过整体流程，应该没啥问题。
然而，我想多了。

这一天新来的小伙子就修漏洞，我没管他，我也有自己的工作好吗，为这事儿我已经耽搁很多工作了。
然后晚上快买票了，我召唤了那个小伙子，说快买票了，你去系统测试下线上的有没有问题。
他说好。

然后他就没给我回音了。
我以为没事儿，就没管他们了。

结果朋友在快八点的时候从客户那边给我电话说，怎么回事没有一点数据，还要给客户演示的这下麻烦了。我心想不是正常吗啥没有数据。
于是我赶紧去现场测了一下，卧槽没法下单，下单的时候500错误！

跟他对话完我已经没心思骂他了，尼玛我让你现在测你拿着昨天的东西说可以到底是几个意思。  
我觉得此刻也根本没法依赖他了，依赖他的靠谱程度还不如我的三脚猫PHP功夫。
后来证明确实没法依赖他，因为问他啥事儿都没回应，最后干脆跟我说，啥都不知道。

还有比这更离谱的事儿吗？想骂人都骂不出来。
后来我直接撇开了他，还求助了同事关于ThinkPHP的细节，终于在四十分钟后找到了错误日志，错误日志显示数据约束错误，然后继续往前面捋代码，发现是登录的时候写到Session里的数据缺少了一个必须字段，导致数据库报错了。
而登录代码之所以会变动，是因为只对密码MD5没加盐，这个新来的技术小伙子觉得不安全，自己改了加盐的代码。

且不说加盐是不是应该在这种时候改，改完了都不测试一下流程吗？！  
我完全不知道怎么吐槽了。
而就在半个小时前，已经通过前端跳转，将所有业务重定向到淘宝上去了。

九点半的时候我从公司走，朋友来电话说，他被踢了，因为那个技术员干脆把手机关机，彻底不接他电话了……

再后来就是，因为这连续两次彻底的掉链子，不仅新的业务没拿下来，之前的既有业务基本上也都黄了。

于是……后来这位朋友就联系不到了。  

这充分说明了自己手下人靠谱程度其实直接决定了你的业务能不能活下去。

争取最后机会

朋友觉得还有机会可以争取，所以问我怎么办比较好。
于是我决定给他搭一套新的东西。既然Server2012到Server2012有问题，那简单，负载均衡换成CentOS不就好了。
于是从来没有部署过线上CentOS服务器的我，竟然能摆平MySQL+Tengine+PHP，所有的业务都能跑通，连自己都开始佩服自己了，连编译安装都搞定了。
当然PHP是跑在CentOS7本机的，没有跑在Windows上，虽然依然有一台Windows Server 2012。

等等，之前的性能问题没有下文了？
NONONO。

依然是那狗屁的性能

虽然现在没有反代的需要了，但我依然用ab从各个平台之间互相压测了一下看看是不是有问题。
然后！我就发现有问题了。
而且这个问题很奇怪的，Server2012压CentOS没问题，两台机器本机压测没问题，但是Server2012压测CentOS依然出了问题，而且是大问题。

为了清晰地表述问题，我将用数据来说话。  

首先说一下测试环境。

• 服务器A：CentOS7，Tengine最新版
• 服务器B：Windows Server 2012，IIS8
• 用来测试的文档分为三个，分别为1KB，2KB，4KB。

首先我们在CentOS上本机压测，分别测试1K、2K、4K的文档，在并发500下的性能。

从上面的结果可见，CentOS本机压测的时候，吞吐率基本上维持在9000+RPS，比较正常的表现。

然后我们再看下CentOS压Server2012的表现。

可见，虽然不是本机是通过网络的，但性能还是挺高的，在文件不大的情况下，比Tengine本机测试都高。

好像没有问题，从服务器到网络都没有问题对吗？
错！图样图森破！桑塔么司乃衣服！！  

看看Server2012压测CentOS的结果！！

是不是看到了相似的一幕？是的，这里都是500并发，但是文件越大速度越慢，2K的时候已经跌破了100RPS，而到4K的时候，已经彻底完成不了了——反复测试了很多次，每次都会在最后几个的时候挂掉。

看到这里，我气不打一处来。  
让朋友去阿里提交工单。

然后他们的反馈是！！！

……好嘛，这回赖ab工具了，好吧，工具有问题。
我现在才发现，之前的那个旺旺上的工作人员，也是这么回复我的。

呵呵，ab有问题。
呵呵，打脸什么的我最喜欢了。  

反正我能找到另外的服务器来测试。
找不到就偷。

哪怕并发加到1000也并不会导致性能有怎么降低。

要知道，这测试的内网还是100M带宽而已，并不是千兆的。

作为被我打脸的回应。

……建议用PTS来测。PTS是啥呢……

哦。呵呵……  

结束

写得我累死了，八十多页的Word文档。

总的来说就是，这事儿黄了，Over。

最后项目没有能继续，朋友也心灰意冷，仅此而已。

感谢阅读本文，欢迎扫描下方二维码关注鱼的公众号（微信内长按识别哦）