一条失去条件的动态 SQL,到手的年终奖飞了

01/24 12:54
阅读数 8

前言

好了,进入今天的正文,今天想跟大家聊聊一次 mybatis 动态 SQL 引发的生产事故。

事情这样的,我们有个订单相关数据库服务,专门负责订单相关的增删改查。这个服务运行了很久,一直都没有问题。

直到某天中午,正想躺下休息一下,就突然接到系统报警,大量订单创建失败。订单服务可以说是核心服务,这个服务不可用,整个流程都会被卡主,交易都将会失败。

马上没了睡意,立刻起来登上生产运维机,查看订单服务的系统日志。

Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-xxip, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 165633 (completed: 165433), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in 1!
        at com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport.rejectedExecution(AbortPolicyWithReport.java:53)
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:768)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:656)
        at com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler.caught(AllChannelHandler.java:65)

如上所示,日志中打印大量的 Dubbo 线程池线程耗尽,直接拒绝服务调用的日志。登上另一台机器,好家伙,除了上述日志以外,仔细翻看居然还发生 「OOM」!!!

其实发生 「OOM」 了,问题倒是简单了,首先 「dump」 一下,然后分析一下生成的日志,查找内存占用最大类,然后分析定位具体代码块。

结合系统日志以及 dump 日志,我们很快就定位到发生问题的代码位置,样例代码如下:

Order order=new Order();
log.info("订单查询参数信息:{}",order);
// 其他系统逻辑,关键信息数据加密等
List<Order> orderList = orderMapper.query(order);
// .. 其他查询逻辑

查询底层使用 mybatis 动态 sql 功能,样例如下:

<select id="query" parameterType="order" resultMap="orderResultMap">
    select orderId,amt,orderInfo // 还有其他信息
    from
    Order
    <where>
        <if test="orderId != null">
            orderId = #{orderId}
        </if>
        <if test="amt != null">
            AND amt = #{amt}
        </if>
       ..... 其他条件
    </where>
</select>

上面的代码很简单,由于传入 mybatis 查询语句参数都未设置,从而导致生成的 sql 缺失了查询条件了,查询全表。

而由于订单表的数据非常多,全表查询返回的数据将会源源不断的加载到应用内存中,从而引发 「Full GC」,导致应用陷入长时间的 「stop the world」

由于 Dubbo 线程也被暂停了,接收到正常的调用无法及时返回结果,从而引发服务消费者超时。

另一方面,由于应用不断接受请求,而大量 Dubbo 线程不能及时处理调用,从而导致 Dubbo 线程池中线程资源被耗尽,后续请求将会被直接拒绝。

最后最后,系统应用内存实在无法再加载任何数据,于是抛出上文中 「OOM」 异常。

这张图真的体现小黑哥当时心态变化

问题本质原因是找到了,那为什么之前查询都没事,而这次突然就没传值了呢?

原来是因为前端页面改动,导致传入的查询参数为空!!!

前端页面迟迟不能显示查询的订单,用户一般会选择重试,然后又未传入查询参数,再一次加重应用的情况,雪上加霜。

扩展思考

上面的问题,我们只要重启应用,暂时还是能解决问题。想象一下如果使用动态 sql 发生在其他场景,会怎么样?

假设用户的余额表使用动态 sql 更新,这时如果条件丢失将会导致全部用户的余额都会发生了变化。如果是余额变多,那可能还好。但是如果余额是变少的,那真的很可能演变成社会事故了~

我们再假设下,如果某些配置表使用了动态 sql 物理删除数据,这时如果条件丢失将会导致全表数据被删。数据如果都没了,没什么好说了,跑路吧~

可以看到,更新/删除这类动态 sql,如果丢失了条件,那导致的危害将会很大,业务可能都会被停摆。

解决办法

那有没有什么办法解决这些问题?

「很简单,不要用动态 sql 了,直接手写吧~」

emm!你们先把刀放下,我开个玩笑的~

虽然上面的问题确实是动态 sql 引起的,但是本质原因我觉得还是使用不当引起的。

我们肯定不能因噎废食,自废武功,从此退回到「刀耕火种」时代,手写 sql。

好了,不说废话了,解决动态 sql 带来潜在的问题,我觉得可以从两方面下手:

第一、改变意识形态,科普动态 sql 可能引发的问题,让所有开发对这个问题引起重视。

只有当我们意识动态 sql 可能引发的问题,我们才有可能在开发过程去思考,这么写会不会被带来问题。

「这一点,我觉得真的很重要。」

第二,针对实际的业务场景提供可控的查询条件,并且对外接口一定要做好必要的参数校验。

我们要从实际的业务场景出发分析对外需要提供那些条件,原则上主库表必须按照主键或唯一键查询单条,或者使用相关的外键查询多条。比如说,订单表查询支付单号这类主键查询。

另外针对这些查询条件,接口层一定要做好的必要的参数校验。如果参数未传,直接打回,防患于未然。

如果真的有需要查询多条数据后台需求,这类查询不需要很高实时性,那么我们其实可以与上面应用查询剥离开来,并且查询使用从库。

第三,增加一些工具类预防插件。

比如我们可以在 mybatis 增加一个插件,检查执行的 sql 是否带有 where 关键字,若不存在直接拦截。

mybatis 拦截器如下:

@Intercepts({
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class,
                RowBounds.class, ResultHandler.class}),
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class,
                RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}),
        @Signature(type = Executor.class, method = "update", args = {MappedStatement.class,
                Object.class})})
@Slf4j
public class CheckWhereInterceptor implements Interceptor {

    private static final String WHERE = "WHERE";

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        //获取方法的第0个参数,也就是MappedStatement。@Signature注解中的args中的顺序
        MappedStatement mappedStatement = (MappedStatement) invocation.getArgs()[0];
        //获取sql命令操作类型
        SqlCommandType sqlCommandType = mappedStatement.getSqlCommandType();
        final Object[] queryArgs = invocation.getArgs();
        final Object parameter = queryArgs[1];
        BoundSql boundSql = mappedStatement.getBoundSql(parameter);
        String sql = boundSql.getSql();
        if (Objects.equals(SqlCommandType.DELETE, sqlCommandType)
                || Objects.equals(SqlCommandType.UPDATE, sqlCommandType)
                || Objects.equals(SqlCommandType.SELECT, sqlCommandType)) {
            //格式化sql
            sql = sql.replace("\n", "");
            if (!StringUtils.containsIgnoreCase(sql, WHERE)) {
                sql = sql.replace(" ", "");
                log.warn("SQL 语句没有where条件,禁止执行,sql为:{}", sql);
                throw new Exception("SQL语句中没有where条件");
            }
        }
        Object result = invocation.proceed();
        return result;
    }

    @Override
    public Object plugin(Object target) {
        return Plugin.wrap(target, this);
    }

    @Override
    public void setProperties(Properties properties) {

    }
}

上面的代码其实还是比较粗糙,各位可以根据各自的业务增加相应的预防措施。

小结

今天的文章,从真实的例子出发,引出了动态 sql 潜在的问题,主要想让大家意识到这方面的问题。从而在今后使用动态 sql 的过程中更加小心。

推荐阅读

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部