資訊專欄INFORMATION COLUMN
某業務系統由于請求的加載數據超過JVM堆內存設置，引發了集群異常。檢查集群的任何命令已無法返回。
某天晚上，短信大把告警，es集群健康告警，無法連接，同時應用也反饋報表查詢失敗，為盡快恢復故障，急急忙忙登陸到相關機器，查詢直接返回circuitbreakingexception報錯，這個問題以前未遇到過，于是從問題本身進行分析，下面是本次事件的一些說明，和大家作此分享。
ES檢索數據的過程，大概是這樣的，客戶端發送請求到一個coordinate node，在這里就是隨機的一節點收到請求，根據請求得到對應數據的分片，路由到各個shard去搜索結果，由協調節點進行數據合并、排序、分頁等操，最終產生一個結果返回給客戶端；
通過這個原理，數據加載到內存，堆內存不夠當前查詢加載數據所需要就會報data too large, circuitbreakingexception異常請求被熔斷，那么這個問題的方向就基本確定了，要么內存設置不夠，要么應用程序太差引起，我們于是開展下面工作。
我們先看一下機器所屬的JVM是否太小引起的，于是看看32G，已是最佳配置。
配置中，內存夠用，那可能就是另一種情況，是應用程序本身的問題，我們可通過開啟es慢日志監控，在慢查詢日志中查找到有以下查詢記錄日志:
取一條記錄的查詢語句，查詢的是tbsmpsmsreport202109索引，以下為格式化處理后的查詢dsl語句，嵌套7層聚合查詢，消耗大量內存，導致后續請求被熔斷。
{
"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查詢，可判斷出其邏輯復雜，多層次聚合，ES大多數時候對單個字段的聚合查詢還是非常快的， 但是當需要同時聚合多個字段時，就可能會產生大量的分組，最終結果就是占用 es 大量內存，從而導致 OOM 的情況發生, 而且隨著數據量的增長，聚合查詢消耗的內存也會更多，所以es中應盡量避免聚合查詢。
于是結合實際的結果，本案請求被熔斷異常，是由于tbsmpsmsreport202109索引嵌套7層聚合查詢引起的，而聚合查詢會消耗大量內存，而該請求嵌套了7層聚合，消耗的內存更多，導致目前出現的請求被熔斷現象，后續還可能出現更嚴重的OOM內存耗盡導致集群掛掉現象，由于要結合業務，我們把對應語句，反饋給應用，優化es查詢。
在現今各種數據庫風云變幻的時代， 不再是某數據庫或多某數據庫壟斷的時候了，數據庫技術已細化到某一個領域甚至某一個場景，當我們使用的時候要盡量去使用它的長處，要知道存在即合理的道理，通過整合數據庫生態造就一個最穩定、最佳的基準環境提供給應用，提高最終應用端感知。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129758.html
摘要：這里有一份面試題相關總結，涉及高并發分布式高可用相關知識點，在此分享給大家，希望大家能拿到一份理想的知識點會陸續更新在上，覺得還算湊和的話可以關注一下噢高并發架構消息隊列為什么使用消息隊列消息隊列有什么優點和缺點都有什么優點和缺點如何保證消 這里有一份面試題相關總結，涉及高并發、分布式、高可用相關知識點，在此分享給大家，希望大家能拿到一份理想的 Offer！ 知識點會陸續更新在 Git...
摘要：熔斷機制為了防止雪崩效應事件的發生，分布式系統采用了熔斷機制。為了解決這一難題，微服務架構引入了熔斷機制。由于微服務系統是分布式系統，服務與服務之間沒有任何的禍合。 1.2.1 什么是微服務 按業務劃分為一個獨立運行的程序，即服務單元。 服務之間通過 HTTP 協議相互通信。 自動化部署。 可以用不同的編程語言。 可以用不同的存儲技術。 服務集中化管理。 微服務是一個分布式系統。 ...
摘要：我們將直接向發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務我們將看到以下的輸出我們也能看到我們五次的調用成功了。 本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。 這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分） 重試/超時（第二部分） 分布式跟蹤（第三部分） Prometheus的指標...
摘要：我們將直接向發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務我們將看到以下的輸出我們也能看到我們五次的調用成功了。 本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。 這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分） 重試/超時（第二部分） 分布式跟蹤（第三部分） Prometheus的指標...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
