生产问题汇总记录（自查）

环境迁移引来的事故

问题背景：

因某些业务原因，需迁移db存储源。

实施过程：

因当前系统日益庞大，待有很多需要优化的地方。遂迁移存储源、代码优化、迭代一起改动，进行上线。

落地结果：

线上出现问题，需要回滚，没有梳理回滚方案。含泪奔跑，下游系统欲哭无泪。

问题感想：

相关较大迁移的操作，切不可操之过急，一步一步的进行。

spring代码版事务connection close

问题背景：

spring事务分为注解版和代码版事务。

因某些场景需要针对回滚情况特殊处理，有因注解版事务对使用人员要求相对较高。遂采用代码版事务。

问题现象：

当前系统最近1个月无相关迭代上线，线上报出connection close问题，对堆栈信息查看后，为一个简单的查询，或存在了很久并未改动过的update/insert操作等。即日志信息无协助排查意义。但该问题爆出并无规律。线上3台机器，均有问题，无固定触发时间点，无固定触发操作。

问题分析：

该问题一定为数据库配置问题，导致数据库连接池出现了坏连接。针对该问题处理采用了

1.检查了数据源配置，乃至和生产其他系统中稳定的数据源配置进行对比，无问题。

2.增加相关数据源配置，每次请求都判断当前连接是否生效的配置testOnBorrow，也无解决（重新部署后，过几天仍然有该问题爆出）。

3.联系dba，反馈为数据源配置问题。dba协助排查也无问题，dba断言肯定为数据源配置问题。整个沟通周期较长(dba在上海职场)，dba后来打开了‘消失’模式。

4.继续跟进数据源配置问题，发现当前数据源为tomcat-jdbc，tomcat-jdbc存在丢连接的情况，修改使用为内部自研的数据源（其实某版本之后就默认使用自研的数据源，无关显示配置），问题仍未解决。

5.一刹那，想到会不会是基于连接池操作的sql事务没关的原因。

将当前系统针对事务的地方，进行代码review。发现有某处场景处理，开启事务后，当某条件不满足，直接进行return（return之前有条日志信息，未进行事务回滚）。针对该日志以最近重新部署（问题未解决之前，一直采用重新部署的方式来解决）的时间起，每台机器的每天日志信息均进行查看，发现该日志存在，且该日志出现后不久就报该异常。

解决方案：

将相关的return操作之前增加事务回滚操作，且制定规范相关spring代码版事务操作中，事务开启后不允许在事务内进行return操作，均采用抛异常的形式，抛到catch中统一rollback。

问题感想：

针对线上问题出现时，先稳定心态。不要陷在局限思维中，节省问题排查时间。

线程池导出同步变异步（多线程并行跑数据），结果更慢

问题背景：

因为导出数据过多，接口响应超过1s，不满足公司qop要求，进行改造。遂进行同步变异步，且并行处理。

问题现象：

异步处理时根据要导出的数据量进行拆分，每查询500条数据的相关操作为1个任务放到线程池受理。

导出时因为要关联信息进行组装进行查询，可能会涉及到调上游接口、查缓存、查其他表等，但30w的数据导出甚至有时需要2分钟。

问题分析：

查看日志信息发现每个查询任务大致耗时约0.5s，发现日志中的线程号为同一线程处理，并没有实现并行的效果。

查看线程池，发现配置有极大问题。corePoolSize为1，queueCapacity为60000。了解线程池配置的同学应该明白，只有当queueCapacity满了之后且小于maxPoolSize，才会创建新线程来处理任务。

问题原因：

因为线程池的配置不合理，导致多线程的处理变成了单线程的效果。

解决方案：

修改线程池配置信息

问题感想：

前人挖坑，后人深陷其中。合理利用线程池配置信息。

sql优化总结

问题背景：

随着数据量的剧增， sql执行耗时超过1s，不满足qop的指标要求，遂进行改造。

解决方案汇总（基于sql优化的基础）：

整体分为业务优化+技术优化

1.全量模糊匹配，协调产品和用户沟通采用最左匹配原则（业务优化）

2.查看相应索引是否生效，是否为理想中的索引，如果不是，采用强制做索引的方式。（技术优化）

3. 因sql执行耗时超过1s为硬性要求，又因非主键索引会进行回表操作，遂采用回表操作拆分的形式。1条sql折合成2条。

    第1条只查询id（避免回表）；
   
    第2条根据id查询需要的数据信息（手动回表）。
   

4. 根据业务关系，多表合并成单表，避免关联表查询。

问题感想：

sql优化方式有很多，较好的方式沉淀是根本。

显示delete的事故

问题背景：

因增加了某些条件，需失效用户信息。（该问题为其他事业部的coe，因某次小迭代，未进行codeReview、rd自测上线，导致该事故。）

问题现象：

影响集团内部所有系统不能正常运行

问题原因：该系统采用了物理删除的形式， 因某场景没有match到，导致在执行删除语句的时候没有where条件。

解决方案：

dba进行数据恢复。

问题感想：

相关系统设计时，无论如何不可使用物理删除逻辑，应采用逻辑删除。