一次Debug过程的思考

前一段时间，部门接入了新业务，由于业务量小，架构非常简单，采用了最简单的LNMP架构，整个项目是交给一个刚毕业的RD负责的，这是背景。

    上线前半天，服务平稳运行。下午的时候，开始收到大量报警：No host could be connected in the cluster。第一反应：mysql服务器不会挂了吧。打开监控，一切正常，登录也一切正常，但报警一直没有间断，这奇怪了。

    实际上一点都不奇怪。“No host could be connected in the cluster”本身不是mysql的错误，所以并不是mysql服务器本身出了问题，问题的原因一定是出在封装的底层的类库，为了描述的更明白一些，我先总结一下这个mysql连接管理类库的功能。

    为了保证mysql服务的稳定性，我们的mysql连接类库实现了一个故障自动切换的功能：维护一个当前的mysql服务器的列表，每次连接时随机选择一台服务器连接（这里不考虑跨机房的问题，也不考虑选择的算法。选择机器的算法可以是随机的，也可以是轮询的，这不是关键），同时维护一个失败的服务器列表。如果某一次mysql执行失败，那么便把这台服务器从可用的服务器中摘除，同时放置到失败的服务器列表中， 在一定时间内（interval,比如2s）这台mysql便不在被访问。 需要注意的是，这台mysql并不是一直在失败的服务器列表中的，经过一段时间后，便会重新释放，重新进入可用的服务器列表中。这么做的主要目的，是在某一台mysql服务器发生故障时，由于这台mysql被访问到的概率变小，不至于出现线上服务的大面积瘫痪，也给线上故障转移提供更多的时间buffer。

    问题就出在这里！这个自动切换的功能只适用于mysql cluster，也就是存在多个mysql服务器的情况，如果服务器只有一台，那么问题就很严重了：如果某一次mysql查询执行失败了，那么这台mysql会被打入冷宫，在接下来的时间间隔内，便没有任何可用的mysql服务器了！这样一来，流量一大，所有的interval间隔内的请求便都失败了！这也是为什么线上会出现大量的“No host could be connected in the cluster”的报警。

    这个问题很典型，很多人不清楚类库的作用，便信手拈来直接使用，所以出现问题的时候常常也是一头雾水，不知从何下手。尤其在大公司中，类库、工具、成熟的解决方案都比较齐全，在使用方便的同时，也隐藏了内部的实现逻辑，往往会造成“使用很熟练，原理一窍不通”的问题。