核心内容摘要
麻花影视免费观看
那是一个休闲的周六上午我吃着面突然看到工作群信息两条告警信息
生产数据库异常。
下单业务连接数据库失败......不是吧阿sir这种事都能让我碰到手中的面突然不香了。
接着领导信息接踵而来我说赶紧先让运维重启数据库服务器吧我也没权限操作数据库服务器呀。
说完大量吸入手中的拌面赶紧回家看看问题。
业务背景数据库主从类似keepalived的机制主从都安装keepalivedkeepalived会定期检测心跳主机器挂了会进行vip飘移。
简单来说就是访问43VIP就是访问41检测到41挂了就会进行VIP漂移和数据库主从切换。
一开始是说vip没飘过去我就说赶紧重启41。
。
不然没法玩后面说已经飘过去了43是能访问的但是程序还是有问题。
我还以为是43访问不了那就和程序没有关系原来还是有关系的....。
然后运维重启了在线系统问题解决。
问题定位因为运维重启前没有打印线程快照所以只能通过业务日志的时间去定位问题.....首先记录几个时间故障发生时间 11:36:28 - 11:54:30最后一次HTTP请求返回11:37:13路径tomcat的logs目录下localhost_access_log.
-
txt第一次系统报错时间113721路径:catalina.out确定在36分半的时候数据库已经挂了在线系统的请求全卡在请求数据库那里然后坚持了差不多一分钟就无法处理请求了。
系统卡了20分钟重启后恢复。
故障分析为什么获取数据库连接失败没有抛异常呢因为c3p0连接池的5秒超时被注释掉了。
。
为什么注释掉了呢这要追溯到上一次的生产事故了...大概就是某一天的并发很高然后系统网络又有点卡顿导致数据库连接数满了有一些连接请求数据库5秒后就抛异常了最关键的是..系统try catch把异常吞了导致没有触发重试机制。
然后领导就觉得让他慢慢消费也可以就注释掉了。
这其实算是一个策略数据库连接池满了到底怎么处理如果是短时间内的堵塞可以让他慢慢消费如果是长时间的堵塞就只能抛异常了。
就要从结果来说还是要设置超时时间比较好就不会导致请求堵塞。
。
为什么会报C3P0的死锁网上搜c3p0 APPARENT DEADLOCK发现一大堆案例。
我以为是因为这个死锁导致的系统崩溃结果在本地环境能复现这个问题。
我是本地搭了一个数据库然后没有启动服务连接池连不上就会报这个错误。
接着我尝试访问下单接口看看多久返回2分钟。
。
直接卡死如果设置了超时时间接着我再把本地数据库打开系统正常访问所以问题是和c3p0死锁没有关系就是请求全堵塞了。
优化方案
设置超时时间5秒虽然可能会抛弃一部分请求但是不至于堵塞整个系统
业务拆分把关键业务和非关键业务分开部署现在是由于一个上报接口并发太高导致tomcat连接数和数据库连接数都用完了后期还能根据业务拆分数据库。
加大tomcat连接和c3p0数据库连接数现在tomcat默认200的连接数c3p0最大设置200要把这两个参数翻倍让系统再坚挺一会儿。
数据库主从切换时间要更迅速一点一分多钟才切换成功有点久了
告警出现值班运维要马上查看系统cpu和内存使用情况如果出现异常需要记录下来并打印线程快照最后重启服务。
总结由于主库挂了导致4台集群无法工作就是因为一个超时时间的问题也确实不应该。
只能用要多想想一些特殊的情况比如数据库挂了怎么办线程池满了怎么办http请求超时怎么办。
一个大事故的发生都是多个小问题引起的。
另外微服务思想也是重要的不能因为某个小业务并发高导致系统堵塞。