ES集群請(qǐng)求熔斷誰的鍋

IT那活兒發(fā)布于2023-01-11 13:20 / 1911人閱讀

ES集群請(qǐng)求熔斷誰的鍋

故事描述

某業(yè)務(wù)系統(tǒng)由于請(qǐng)求的加載數(shù)據(jù)超過JVM堆內(nèi)存設(shè)置，引發(fā)了集群異常。檢查集群的任何命令已無法返回。

故事發(fā)生過程

某天晚上，短信大把告警，es集群健康告警，無法連接，同時(shí)應(yīng)用也反饋報(bào)表查詢失敗，為盡快恢復(fù)故障，急急忙忙登陸到相關(guān)機(jī)器，查詢直接返回circuitbreakingexception報(bào)錯(cuò)，這個(gè)問題以前未遇到過，于是從問題本身進(jìn)行分析，下面是本次事件的一些說明，和大家作此分享。

ES檢索數(shù)據(jù)的過程，大概是這樣的，客戶端發(fā)送請(qǐng)求到一個(gè)coordinate node，在這里就是隨機(jī)的一節(jié)點(diǎn)收到請(qǐng)求，根據(jù)請(qǐng)求得到對(duì)應(yīng)數(shù)據(jù)的分片，路由到各個(gè)shard去搜索結(jié)果，由協(xié)調(diào)節(jié)點(diǎn)進(jìn)行數(shù)據(jù)合并、排序、分頁等操，最終產(chǎn)生一個(gè)結(jié)果返回給客戶端；

通過這個(gè)原理，數(shù)據(jù)加載到內(nèi)存，堆內(nèi)存不夠當(dāng)前查詢加載數(shù)據(jù)所需要就會(huì)報(bào)data too large, circuitbreakingexception異常請(qǐng)求被熔斷，那么這個(gè)問題的方向就基本確定了，要么內(nèi)存設(shè)置不夠，要么應(yīng)用程序太差引起，我們于是開展下面工作。

我們先看一下機(jī)器所屬的JVM是否太小引起的，于是看看32G，已是最佳配置。

配置中，內(nèi)存夠用，那可能就是另一種情況，是應(yīng)用程序本身的問題，我們可通過開啟es慢日志監(jiān)控，在慢查詢?nèi)罩局胁檎业接幸韵虏樵冇涗浫罩?

取一條記錄的查詢語句，查詢的是tbsmpsmsreport202109索引，以下為格式化處理后的查詢dsl語句，嵌套7層聚合查詢，消耗大量內(nèi)存，導(dǎo)致后續(xù)請(qǐng)求被熔斷。

{
  "query": {
    "range": {
      "CREATE_DATE": {
        "from": "2021-09-26 00:00:00",
        "to": "2021-09-26 23:59:59",
        "include_lower": true,
        "include_upper": true,
        "boost": 1.0
      }
    }
  },
  "track_total_hits": 2147483647,
  "aggregations": {
    "channelTypeSum": {
      "terms": {
        "field": "CHANNEL_TYPE",
        "size": 10,
        "min_doc_count": 1,
        "shard_min_doc_count": 0,
        "show_term_doc_cou nt_error": false,
        "order": [{
          "_count": "desc"
        }, {
          "_key": "asc"
        }]
      },
      "aggregations": {
        "sysCode": {
          "terms": {
            "field": "SYS_CODE",
            "size": 10,
            "min_doc_count": 1,
            "shard_min_doc_count": 0,
            "show_term_doc_co unt_error": false,
            "order": [{
              "_count": "desc"
            }, {
              "_key": "asc"
            }]
          },
          "aggregations": {
            "bussinessIdSum": {
              "terms": {
                "field": "BUSINESS_ID",
                "size": 10,
                "min_doc_count": 1,
                "shard_min_doc_count": 0,
                "show_ term_doc_count_error": false,
                "order": [{
                  "_count": "desc"
                }, {
                  "_key": "asc"
                }]
              },
              "aggregations": {
                "lantId": {
                  "terms": {
                    "field": "LATN_ID",
                    "size": 10,
                    "min_doc_count": 1,
                    "shard_min_doc_count": 0,
                    "show_t erm_doc_count_error": false,
                    "order": [{
                      "_count": "desc"
                    }, {
                      "_key": "asc"
                    }]
                  },
                  "aggregations": {
                    "fromTel": {
                      "terms": {
                        "field": "FROM_TEL",
                        "size": 10,
                        "min_doc_count": 1,
                        "shard_min_doc_count": 0,
                        "show_ term_doc_count_error": false,
                        "order": [{
                          "_count": "desc"
                        }, {
                          "_key": "asc"
                        }]
                      },
                      "aggregations": {
                        "rpErrCode": {
                          "terms": {
                            "field": "RP_ERR_CODE",
                            "size": 10,
                            "min_doc_count": 1,
                            "shard_min_doc_count": 0,
                            "show_term_doc_count_error": false,
                            "order": [{
                              "_count": "desc"
                            }, {
                              "_key": "asc"
                            }]
                          },
                          "aggregations": {
                            "createDate": {
                              "date_histogram": {
                                "field": "CREATE_DATE",
                                "format": "yyyy-MM-dd",
                                "interval": "1d ",
                                "offset": 0,
                                "order": {
                                  "_key": "asc"
                                },
                                "keyed": false,
}

上面的這條ES查詢，可判斷出其邏輯復(fù)雜，多層次聚合，ES大多數(shù)時(shí)候?qū)蝹€(gè)字段的聚合查詢還是非?？斓模?但是當(dāng)需要同時(shí)聚合多個(gè)字段時(shí)，就可能會(huì)產(chǎn)生大量的分組，最終結(jié)果就是占用 es 大量內(nèi)存，從而導(dǎo)致 OOM 的情況發(fā)生, 而且隨著數(shù)據(jù)量的增長，聚合查詢消耗的內(nèi)存也會(huì)更多，所以es中應(yīng)盡量避免聚合查詢。

于是結(jié)合實(shí)際的結(jié)果，本案請(qǐng)求被熔斷異常，是由于tbsmpsmsreport202109索引嵌套7層聚合查詢引起的，而聚合查詢會(huì)消耗大量內(nèi)存，而該請(qǐng)求嵌套了7層聚合，消耗的內(nèi)存更多，導(dǎo)致目前出現(xiàn)的請(qǐng)求被熔斷現(xiàn)象，后續(xù)還可能出現(xiàn)更嚴(yán)重的OOM內(nèi)存耗盡導(dǎo)致集群掛掉現(xiàn)象，由于要結(jié)合業(yè)務(wù)，我們把對(duì)應(yīng)語句，反饋給應(yīng)用，優(yōu)化es查詢。

故事發(fā)生引發(fā)的思考

在現(xiàn)今各種數(shù)據(jù)庫風(fēng)云變幻的時(shí)代，不再是某數(shù)據(jù)庫或多某數(shù)據(jù)庫壟斷的時(shí)候了，數(shù)據(jù)庫技術(shù)已細(xì)化到某一個(gè)領(lǐng)域甚至某一個(gè)場景，當(dāng)我們使用的時(shí)候要盡量去使用它的長處，要知道存在即合理的道理，通過整合數(shù)據(jù)庫生態(tài)造就一個(gè)最穩(wěn)定、最佳的基準(zhǔn)環(huán)境提供給應(yīng)用，提高最終應(yīng)用端感知。