前言 笔者最近解决了一个困扰了业务系统很久的问题.这个问题只在发布时出现,每次只影响一两次调用,相较于其它的问题来说,这个问题有点不够受重视.由于种种原因,使得这个问题到了业务必须解决的程度,于是就到了笔者的手上. 问题现场 我们采用的是dubbo服务,这是个稳定成熟的RPC框架.但是我们在某些应用中会发现,只要这个应用一发布(或者重启),就会出现请求超时的问题,如下图所示: 而且都是第一笔请求会报错,之后就再也没有问题了. 排查日志 好了,现象我们知道了,于是开始排查那个时间点的日志.Serv…

前言 dubbo是一个成熟且被广泛运用的框架.饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题.由于此问题容易导致比较大的故障,所以笔者费了一番功夫去定位,现将排查过程写成博文分享出来. Bug现场 这是一起在测试环境出现的故障.起因是网工做交换机切换演练,可能由于姿势不对,使得断网的时间从预估的秒级达到了分钟级.等网络恢复后,测试环境就炸开了锅,基本上所有应用再也无法提供服务,在dubbo控制台上也看不到任何提供者,他们和zk的连接都断开而且似乎完全没有重…

解Bug之路-Nginx 502 Bad Gateway 前言 事实证明,读过Linux内核源码确实有很大的好处,尤其在处理问题的时刻.当你看到报错的那一瞬间,就能把现象/原因/以及解决方案一股脑的在脑中闪现.甚至一些边边角角的现象都能很快的反应过来是为何.笔者读过一些Linux TCP协议栈的源码,就在解决下面这个问题的时候有一种非常流畅的感觉. Bug现场 首先,这个问题其实并不难解决,但是这个问题引发的现象倒是挺有意思.先描述一下现象吧, 笔者要对自研的dubbo协议隧道网关进行压测(这个…

解Bug之路-记一次线上请求偶尔变慢的排查 前言 最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章. Bug现场 这是一个偶发的性能问题.在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过1s,让我们业务耗时监控的99.99线变得很尴尬.如下图所示: 为了精益求精,更为了消除这个尴尬的指标,笔者开始探寻起这100多慢请求笔的原因. 先找一笔看看 由于笔者写的框架预留了traceId,所以找到这笔请求的整个调用的链路还是非常简单的. 而且…

解Bug之路-ZooKeeper集群拒绝服务 前言 ZooKeeper作为dubbo的注册中心,可谓是重中之重,线上ZK的任何风吹草动都会牵动心弦.最近笔者就碰到线上ZK Leader宕机后,选主无法成功导致ZK集群拒绝服务的现象,于是把这个case写出来分享给大家(基于ZooKeeper 3.4.5). Bug现场 一天早上,突然接到电话,说是ZooKeeper物理机宕机了,而剩余几台机器状态都是 sh zkServer.sh status it is probably not running…

解Bug之路-TCP粘包Bug - 无毁的湖光-Al的个人空间 - 开源中国 https://my.oschina.net/alchemystar/blog/880659 解Bug之路-TCP粘包Bug 前言 关于TCP流 TCP是流的概念,解释如下 TCP窗口的大小取决于当前的网络状况.对端的缓冲大小等等因素, TCP将这些都从底层屏蔽.开发者无法从应用层获取这些信息. 这就意味着,当你在接收TCP数据流的时候无法知道当前接收了 有多少数据流,数据可能在任意一个比特位(seq)上. 详情见笔者…

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似…

解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查.今天,笔者就给大家带来一个存储偶发性故障的排查过程. Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件.一直稳定运行,但应用最近确经常偶发连接建立不上的报错.报错如下: GetConnectionTimeOutException 而…

解Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug.现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑. 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget.hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多Redis请求处理不及时,其它业务系统都频繁爆出readTimeOut.此时,紧急将这个…

解Bug之路-NAT引发的性能瓶颈 笔者最近解决了一个非常曲折的问题,从抓包开始一路排查到不同内核版本间的细微差异,最后才完美解释了所有的现象.在这里将整个过程写成博文记录下来,希望能够对读者有所帮助.(篇幅可能会有点长,耐心看完,绝对物有所值~) 环境介绍 先来介绍一下出问题的环境吧,调用拓扑如下图所示: 调用拓扑图 合作方的多台机器用NAT将多个源ip映射成同一个出口ip 20.1.1.1,而我们内网将多个Nginx映射成同一个目的ip 30.1.1.1.这样,在防火墙和LVS之间,所有的请…