如何评价 2015 年 7 月 13 日百度搜索关键字结果皆为链家网广告事件？

我来贴点干货

背景：

17:22 链家网突发的流量猛增，业务报警

17:24 链家网出口带宽全部打满

17:36 php-fpm 不稳定，出现worker耗尽，网站呈现HTTP502，紧急重启php-fpm

17:40 经过多次php-fpm重启，服务无法自行完全恢复，页面呈现出redis无法连接的问题

17:45 通过排查的短连接导致TCP的TIME_WAIT耗尽，紧急修改linux内核参数

17:55 服务恢复正常，流量下降至系统可接受水平

系统原因：

通过排查（其实是通过微信被人 @ 了），流量来自百度品牌专区广告，导致可监测到的异常流量比正常时突增约4倍。

作为一个垂直门户网站，我们的仅仅使用3台前端机器，2台数据库。

经历此次风波，给链家带来的是一次名副其实的线上压力测试。链家网使用如此少的资源，得到的QPS约3.3k。

链家网是如何做到的呢？首先介绍以下我们的架构：

链家网使用的国际流行的LNMP架构（即Linux+Nginx+Mysql+PHP）。

链家网工程团队在很多核心位置采用了Redis和Yac作分级cache系统：在这次“灾难”中，得益于cache的高效使用，才使得系统没有经受更严重的服务雪崩。这种Cache搭配，发挥各种不同cache的优势，在企业级应用中少有使用。

在这次事件中，PHP前端报出Redis连接不上，使得链家网系统的Redis服务中断，但是从Redis运行指标上来看，服务器的状态很健康，没有CPU耗尽，redis的连接数很可控，但是PHP表示连接不上。

由于redis是单点服务，链家网运维团队立刻切换至redis备机，服务恢复正常。好景并不长，很快redis备机也无法建立连接了。

通过排查，发现是TIME_WAIT耗尽导致新的请求无法建立。

链家网运维团队立即在Redis的机器上设置Linux核心参数：net.ipv4.tcp_tw_reuse = 1; net.ipv4.tcp_tw_recycle = 1; 使得redis服务快速恢复，虽然流量还未下降，但是服务已经基本恢复稳定，redis基本问题消除。

利益相关：

链家网架构师 张镇宇

虽然最后还是被压垮了，可是我们就是不服，百度要不再约一战！

可以来聊聊 zhangzhenyu # http://lianjia.com（收简历）