张万信
【故障公告】推荐系统中转站撑爆服务器 TCP 连接引发的故障
来源:蒙帮凡     发布时间: 2019-07-04      浏览次数:322

字号:

上周五下午,我们在博客中部署了推荐系统,在博文下方显示“最新IT新闻”的地方显示自动推荐的关联博文。我们用的推荐系统是第四范式的推荐服务,我们自己只是搭建了一个推荐系统中转站(基于 ASP.NET Core),接收来自博客前端的请求,然后将请求转发给第四范式的推荐服务,并将响应内容转发给博客前端。

这个中转站的功能非常简单,就是一个 http 请求/响应搬运工,简单到让我们忽视了它会给服务器带来的潜在压力 —— 一边与博客前端的请求/响应会产生大量 TCP 连接,一边与推荐服务的请求/响应会产生大量 TCP 连接,而且由于推荐数据的动态变化特点而无法使用缓存。在同样的负载下,这个搬运工会比其他应用消耗更多的 TCP 连接。

从上周五发布到昨天,由于访问量没有达到特别高的高峰,所以问题没有暴露。今天上午访问量达到更高峰时,问题出现了。部署在 docker swarm 集群上的很多站点时不时地出现 500 错误,日志中频繁出数据库或 memcached 服务器网络连接失败的错误。开始我们还以为是之前多次遇到过的节点服务器不稳定问题引起的,于是将集群中的服务器一台一台下线、重启、上线,但这样操作之后问题依旧。接着把怀疑对象放到了 memcached 服务器,是不是 memcached 服务器不稳定引起,于是重启 memcached 服务器,但问题依然。

在用完之前的招式、百思不得其解之时突然想到可能是集群中某些服务器的 TCP 连接过多达到了限制(Linux 的限制或者阿里云的限制),如果站在这个角度分析,不管故障的表现还是日志中的错误都可以得到合理的诠释。于是立马锁定了原因,然后自然就想到了我们上周五部署的推荐系统中转站,赶紧将其下线,500 错误即刻消失,集群上的所有应用都会恢复正常。

非常抱歉,这次故障给大家带来麻烦了,请大家谅解。我们会吸取这次上线推荐系统时不够深思熟虑、过于轻敌的教训,认真反思,努力改进自己的工作。

更新:后来找到了问题的真正原因,详见 放弃等待,故障到来:少一个 await 引发的 tcp 连接泄漏故障

 

, 1, 0, 9);

  • 相关内容: