今天搞定 polling_error 的小记录
今天可真是折腾了一番，碰到了个闹心的 `polling_error`。刚开始也没太当回事，以为是网络抖动一下，或者服务临时抽风，结果这玩意儿跟狗皮膏药似的，一直不停地在日志里冒出来，看着就烦人。
得，看样子是躲不过去了，撸起袖子开始排查。这 `polling_error`，顾名思义，就是轮询出错了呗。简单说就是，我这边有个程序，老是不停地去问另一个服务：“有新消息没？”，结果老是问不到，或者对方直接挂了电话，不理我了。时间一长，可不就报错了嘛
第一步：看看是问谁问出错了
我先是看了看报错日志，找到底是哪个环节在不停地“问”。锁定了是我的一个前端小模块，它定时去后端拉取一个状态信息。行，那问题大概率就出在它问的那个“后端服务”身上。
第二步：检查那个“后端服务”
我就去检查那个后端服务是不是还活着。最简单的，直接试着访问一下那个服务的接口地址。你猜怎么着？直接访问不了，超时或者报错！果不其然，问题就在这儿。看来不是前端小模块的错，是它要问话的那个人联系不上了。
第三步：登录服务器看看后台服务咋了
- 我赶紧登录到跑那个后端服务的服务器上。
- 先看了看进程，服务确实是跑着的，没挂。这就怪了。
- 那就得看服务自己的日志了，看看它在抱怨
翻了半天日志，终于找到点蛛丝马迹。这个后端服务自己也在报错，说是连不上数据库了！得，问题又转移了，原来是更深一层的原因。
第四步：检查数据库
这下目标明确了，就是数据库。我赶紧去检查数据库服务器的状态：
- 数据库服务本身是不是挂了？检查了一下，运行正常。
- 网络通不通？从后端服务那台机器 `ping` 了一下数据库地址，通的。
- 是不是数据库负载太高，忙不过来了？看了看监控，CPU、内存啥的都还行。
这就有点懵了。服务都好好的，网络也通，咋就连接不上？
第五步：尝试重启大法
有时候，很多问题就是这么玄学。既然一时半会儿找不到具体原因，那就试试最简单粗暴但也往往有效的方法——重启。
我小心翼翼地（毕竟是线上环境，得谨慎点）先把那个连不上数据库的后端服务给重启了一下。想着让它重新建立连接试试。
重启完了，观察了一会儿前端那个小模块的日志。那个烦人的 `polling_error` 消失了！再试着直接访问后端服务的接口，也能正常访问了。
问题解决了，但留个心眼
虽然问题暂时解决了，但我心里还是犯嘀咕。为啥好好的就连不上数据库了？重启能解决，说明不是啥硬件或者网络硬伤，更像是一些临时的资源问题或者连接没释放干净之类的“软故障”。
这事儿还没完，我得抽空再仔细看看数据库和那个后端服务的配置，比如连接池大小啥的，或者是不是有慢查询把连接占满了。不然指不定哪天这 `polling_error` 又得跳出来烦我。
今天这个 `polling_error` 的排查过程，就是这么一层一层扒下去，从前端问询，到后端服务，再到数据库，用重启大法暂时搞定。过程挺折腾，但解决了就记录一下，也算是个经验。
