JAVA-DIY-3-WEEK

Persistence is not necessarily successful, but not sure will not succeed.

Posted by Hyuga on March 28, 2019

第三周主题:XY问题

遇到的最山寨的问题

曾今有个功能,dubbo接口调用,目的是根据ids查询对应的汇总数据。

测试环境没有任何问题,预发布环境验证也ok,知道某一天生产环境炸了,还好是分布式系统,其他功能倒不受影响,但是交易相关的服务挂了。。。究其原因,是因为ids数量过于庞大,几万个id丢过去做汇总sql。调用方没有做数量控制,服务方也没做数量校验,导致服务挂了。往大了讲,设计不规范,这种功能就不该用这种方式实现,往小了讲,即便这么做了,做个数量限制,或者分批调用再做数据整合都能避免这种问题,但是,就这么华丽的在线上炸锅了!!!

当时真的是手忙脚乱,一下子不知道问题在哪。一没打日志,二来都在甩锅,导致问题一时半会定位不到,结果迫于业务线压力,只能暂且重启服务先用着,结果不出意外,没过一会,又挂了。最终搞定了,不过也被技术总监每个部门罚个500块张长记性!!!

总结快速定位问题的方法

  • 不要慌乱,凡是调用服务的接口都得加上日志记录,有问题好排查,先由日志入手。
  • 如果没有业务日志,再查看sql日志。
  • 实在不行,直接排查jvm,看下异常线程,定位错误的程序。
  • 如果自己能力有限实在找不出问题,感觉反馈给上面,抓紧时间定位处理,线上问题,再小的问题也是大问题。

彻底解决问题的方法

  • 多学习,多提升,代码能力只是一方面,设计能力,处理问题的能力,这些也是一个研发人员应该具备的。
  • 写程序的时候,一定要多想,想清楚了,想细致了,再来写代码,事半功倍,坑还少。
  • 多总结,多回顾。总结技术,总结处理问题的经验,这些都是以后牛逼的资本。
  • 上面那个问题,最终和产品讨论,换了一个更为有效的实现方式,不用这种漏洞百出的设计方案。