某业务系统由于请求的加载数据超过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那活儿
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/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
