本周扑火之 http client 慢连接问题
短链服务自从上线到现在,已经出了 5 回故障了:
第一次,某著名的刚过百年的大学,紫荆公寓的一个哥们,写了一个诡异的抓站程序,发出来的 http 请求不合法,导致 jetty 缓冲区出错(微博上的直播)。给 Jetty 提了一个 bug,但开发人员说没法重现。我自己写的程序也没法重现当时的情形。自己写了一个 Utf8StringBuilder,覆盖了 Jetty 的版本,增加了出错重置功能,就算 fix 了。
第二次,log 把磁盘写满了。运维人员的低级失误。值得一提的,当时情急之下,直接用 iphone 上的 iSSH 登陆到服务器上 debug 。自那以后,用 iphone 登服务器看 log 就成了一种习惯(看这里)。
第三次,现在看来很可能是 G,F、W 封了国外某个短网址站。而我们的短链里有这样的逻辑:如果是已知的短网址,我们会尝试将其还原成长链接,然后再分配一个我们自己的短网址。当时一堆的 http client 超时,将 http client 线程池占满了,导致其它的 http 请求也发不出去。后来我们拆分了 http client 连接池,将非内网,可能会慢的调用划到一个池子,内网核心调用划到一个池子,其它的调用共用一个池子。这样就能保证互相直接不影响。然后又做了一个开关服务,在紧急情况下,不需要修改代码,甚至不需要修改配置文件重启,直接调用开关接口,就能修改配置项,而且实时生效,将某些受影响的调用跳过。(微博上的直播)
第四次,一个周五下班后的紧急上线,导致下游依赖我们的服务的另一个功能不能正常使用。不巧的是,我和项目组另外一个成员都不方便立即处理,而我当时慌乱之中居然忘了让运维直接回滚,一直想着怎么修改代码,重新发布。sigh 。最后,看到领导发的邮件,才想起直接回滚二进制版本,解决了问题。
第五次,就是今天,内网核心调用连接池满了。没办法,只能切流量,重启,通知对方和网络运维一起来 debug 。好在重启之后,调用顺畅了,bug 算是修复了。只是接下来,如何防止类似的情况再次出现,还是一个大问题。几乎所有的 http client 库都采用连接池技术,而连接池中无可用连接的时候,又都采用排队的办法等待连接。怎么设置才能在不修改底层代码的前提下,让 http 调用不排队等候,直接返回错误呢?代码中自己进行连接计数?好像有点太山寨了点。
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:唐福林 来源: 福林雨-博客
- 标签: 慢连接
- 发布时间:2011-05-25 12:35:46
- [71] Twitter/微博客的学习摘要
- [66] IOS安全–浅谈关于IOS加固的几种方法
- [65] find命令的一点注意事项
- [64] android 开发入门
- [63] 如何拿下简短的域名
- [63] Go Reflect 性能
- [61] Oracle MTS模式下 进程地址与会话信
- [61] 流程管理与用户研究
- [58] 图书馆的世界纪录
- [58] 读书笔记-壹百度:百度十年千倍的29条法则