Broken Pipeline 问题的解决过程

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Broken Pipeline 问题的解决过程》，聊聊MySQL、Java、Socket、nutz，我们一起来看看吧！

昨天线上app出现了奇怪的问题: 先是有用户反馈预约时间功能不可用，我们自己可以重现，但不是每次必现，紧接着很多用户陆续开始反馈。

由于这两天并没有修改线上系统，只能从日志线索来查找，发现查询预约时间表会出现Broken Pipeline的错误，但奇怪的是，这个异常不是在业务代码中触发的，而是所有业务代码执行完毕以后，http response write stream的时候产生的。

上网搜索的时候，发现这个错误表示：通讯的一端主动关闭了socket连接以后，另一端还试图写入造成的。一些文章还提到对于nginx+tomcat的配置，这个问题是由于nginx配置的超时时间不足，超时后主动断开连接导致，或者是app端超时导致。其实这个异常发生的时间距离调用时间非常短（毫秒级），不像是超时导致，但病急乱投医，而且该请求的返回数据量也较大（约500条数据），还是尝试了修改ngin x和app端的超时时间，都没有效果。

后来在查看nginx日志的时候，发现了一个问题：有一个磁盘写入失败的日志记录，由此忽然想到是否磁盘空间不足了，df查看果然如此！！！
清理日志以后，问题解决。

改进思考：
磁盘空间不足问题已经出现过不止一次了，每次都会导致一些莫名其妙，难以定位的问题，为了避免，以后还是应该设置磁盘监控报警，在真正用尽空间之前，就解决它。

本篇关于《Broken Pipeline 问题的解决过程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！