一條失去條件的動態(tài) SQL，到手的年終獎(jiǎng)飛了

前言

好了，進(jìn)入今天的正文，今天想跟大家聊聊一次 mybatis 動態(tài) SQL 引發(fā)的生產(chǎn)事故。

事情這樣的，我們有個(gè)訂單相關(guān)數(shù)據(jù)庫服務(wù)，專門負(fù)責(zé)訂單相關(guān)的增刪改查。這個(gè)服務(wù)運(yùn)行了很久，一直都沒有問題。

直到某天中午，正想躺下休息一下，就突然接到系統(tǒng)報(bào)警，大量訂單創(chuàng)建失敗。訂單服務(wù)可以說是核心服務(wù)，這個(gè)服務(wù)不可用，整個(gè)流程都會被卡主，交易都將會失敗。

馬上沒了睡意，立刻起來登上生產(chǎn)運(yùn)維機(jī)，查看訂單服務(wù)的系統(tǒng)日志。

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 線程池線程耗盡，直接拒絕服務(wù)調(diào)用的日志。登上另一臺機(jī)器，好家伙，除了上述日志以外，仔細(xì)翻看居然還發(fā)生 「OOM」?。?！

其實(shí)發(fā)生 「OOM」 了，問題倒是簡單了，首先 「dump」 一下，然后分析一下生成的日志，查找內(nèi)存占用最大類，然后分析定位具體代碼塊。

結(jié)合系統(tǒng)日志以及 dump 日志，我們很快就定位到發(fā)生問題的代碼位置，樣例代碼如下：

Order order=new Order();
log.info("訂單查詢參數(shù)信息:{}",order);
// 其他系統(tǒng)邏輯,關(guān)鍵信息數(shù)據(jù)加密等
List<Order> orderList = orderMapper.query(order);
// .. 其他查詢邏輯

查詢底層使用 mybatis 動態(tài) 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 查詢語句參數(shù)都未設(shè)置，從而導(dǎo)致生成的 sql 缺失了查詢條件了，查詢?nèi)怼?/p>

而由于訂單表的數(shù)據(jù)非常多，全表查詢返回的數(shù)據(jù)將會源源不斷的加載到應(yīng)用內(nèi)存中，從而引發(fā) 「Full GC」，導(dǎo)致應(yīng)用陷入長時(shí)間的 「stop the world」。

由于 Dubbo 線程也被暫停了，接收到正常的調(diào)用無法及時(shí)返回結(jié)果，從而引發(fā)服務(wù)消費(fèi)者超時(shí)。

另一方面，由于應(yīng)用不斷接受請求，而大量 Dubbo 線程不能及時(shí)處理調(diào)用，從而導(dǎo)致 Dubbo 線程池中線程資源被耗盡，后續(xù)請求將會被直接拒絕。

最后最后，系統(tǒng)應(yīng)用內(nèi)存實(shí)在無法再加載任何數(shù)據(jù)，于是拋出上文中 「OOM」 異常。

問題本質(zhì)原因是找到了，那為什么之前查詢都沒事，而這次突然就沒傳值了呢？

原來是因?yàn)榍岸隧撁娓膭樱瑢?dǎo)致傳入的查詢參數(shù)為空?。。?/p>

前端頁面遲遲不能顯示查詢的訂單，用戶一般會選擇重試，然后又未傳入查詢參數(shù)，再一次加重應(yīng)用的情況，雪上加霜。

擴(kuò)展思考

上面的問題，我們只要重啟應(yīng)用，暫時(shí)還是能解決問題。想象一下如果使用動態(tài) sql 發(fā)生在其他場景，會怎么樣？

假設(shè)用戶的余額表使用動態(tài) sql 更新，這時(shí)如果條件丟失將會導(dǎo)致全部用戶的余額都會發(fā)生了變化。如果是余額變多，那可能還好。但是如果余額是變少的，那真的很可能演變成社會事故了~

我們再假設(shè)下，如果某些配置表使用了動態(tài) sql 物理刪除數(shù)據(jù)，這時(shí)如果條件丟失將會導(dǎo)致全表數(shù)據(jù)被刪。數(shù)據(jù)如果都沒了，沒什么好說了，跑路吧~

可以看到，更新/刪除這類動態(tài) sql，如果丟失了條件，那導(dǎo)致的危害將會很大，業(yè)務(wù)可能都會被停擺。

解決辦法

那有沒有什么辦法解決這些問題？

「很簡單，不要用動態(tài) sql 了，直接手寫吧~」

emm！你們先把刀放下，我開個(gè)玩笑的~

雖然上面的問題確實(shí)是動態(tài) sql 引起的，但是本質(zhì)原因我覺得還是使用不當(dāng)引起的。

我們肯定不能因噎廢食，自廢武功，從此退回到「刀耕火種」時(shí)代，手寫 sql。

好了，不說廢話了，解決動態(tài) sql 帶來潛在的問題，我覺得可以從兩方面下手：

第一、改變意識形態(tài)，科普動態(tài) sql 可能引發(fā)的問題，讓所有開發(fā)對這個(gè)問題引起重視。

只有當(dāng)我們意識動態(tài) sql 可能引發(fā)的問題，我們才有可能在開發(fā)過程去思考，這么寫會不會被帶來問題。

「這一點(diǎn)，我覺得真的很重要。」

第二，針對實(shí)際的業(yè)務(wù)場景提供可控的查詢條件，并且對外接口一定要做好必要的參數(shù)校驗(yàn)。

我們要從實(shí)際的業(yè)務(wù)場景出發(fā)分析對外需要提供那些條件，原則上主庫表必須按照主鍵或唯一鍵查詢單條，或者使用相關(guān)的外鍵查詢多條。比如說，訂單表查詢支付單號這類主鍵查詢。

另外針對這些查詢條件，接口層一定要做好的必要的參數(shù)校驗(yàn)。如果參數(shù)未傳，直接打回，防患于未然。

如果真的有需要查詢多條數(shù)據(jù)后臺需求，這類查詢不需要很高實(shí)時(shí)性，那么我們其實(shí)可以與上面應(yīng)用查詢剝離開來，并且查詢使用從庫。

第三，增加一些工具類預(yù)防插件。

比如我們可以在 mybatis 增加一個(gè)插件，檢查執(zhí)行的 sql 是否帶有 where 關(guān)鍵字，若不存在直接攔截。

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個(gè)參數(shù)，也就是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條件，禁止執(zhí)行,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) {

    }
}

上面的代碼其實(shí)還是比較粗糙，各位可以根據(jù)各自的業(yè)務(wù)增加相應(yīng)的預(yù)防措施。

小結(jié)

今天的文章，從真實(shí)的例子出發(fā)，引出了動態(tài) sql 潛在的問題，主要想讓大家意識到這方面的問題。從而在今后使用動態(tài) sql 的過程中更加小心。

推薦閱讀