当前位置：首页 > news >正文

【橘子ES】熔断器Circuit breaker

news 文章来源：https://blog.csdn.net/liuwenqiang1314/article/details/144382147 2025/1/11 21:56:55

一、相关概念

我们在日常的开发中，关于服务之间的熔断操作似乎很常见，当请求超过了我们服务所认为可以承受的一个上限阈值的时候，我们为了保护服务不会被进一步的高负载压崩溃，我们有时候会选择熔断请求，此时服务不再对外提供服务，处于一种和外界断开的状态，这种操作我们称之为熔断。

而在Elasticsearch 包含多个熔断器，用于防止操作使用过多的内存。每个断路器都会跟踪某些操作使用的内存，并指定它可以跟踪的内存量的限制。此外，还有一个父级 breaker ，用于指定可在所有 breaker 中跟踪的内存总量。

当熔断器达到其限制时，Elasticsearch 将拒绝进一步的操作。此时会触发熔断异常，而我们如何观察这些异常以及如何解决这些异常就显得非常重要。

熔断器不会跟踪 Elasticsearch 中的所有内存使用情况，因此仅提供不完整的保护，以防止内存过度使用。如果 Elasticsearch 使用过多内存，则它可能会遇到性能问题，节点甚至可能会因 OutOfMemoryError 而失败。所以我们不能全部依赖于熔断器，而是需要我们做好关于jvm内存监控来完善我们的集群保护。
下面我们来看一下es中的熔断器。

二、熔断器

1、父级熔断器(parent circuit breaker)

父级断路器可使用以下设置进行配置：

indices.breaker.total.use_real_memory:
该配置为静态配置，所谓静态配置就指的是一旦我们在配置文件中配置好，并且只能在配置文件配置，该配置在服务运行期间无法通过api命令修改。
该配置为布尔类型，默认为true，为true时，父断路器置考虑实际内存使用量，而不会去根据子熔断器的逻辑。
当为false时，仅考虑子熔断器预留的内存量，也就是只看子熔断器的内存配置是不是超了。一般我们这个值就默认即可，父级熔断器是个总的兜底的，下面我们会看到。
indices.breaker.total.limit ：
该配置为动态配置，你可以在集群运行期间随时修改这个值，修改的方式是通过api来操作。
PUT /_cluster/settings
{
“indices.breaker.total.limit”:“80%”
}
他的含义表示的是总体的父级熔断器的一个阈值。如果indices.breaker.total.use_real_memory为false，则默认为JVM堆的70%。如果indices.breaker.total.use_real_memory为true，则默认为JVM堆的95%
换言之就是说，当indices.breaker.total.use_real_memory为默认值true的时候，他这个值就是百分之95，也就是说，当你堆内存占用到达95%的时候，此时会触发父级熔断器，此时你的服务就被熔断了。这其实也没啥，你都95了，再不熔断怕不是要oom了，但是实际上你要观察，如果经常触发95熔断，这时候你可能要对你的服务做一些调整，因为这不正常。而要是indices.breaker.total.use_real_memory为fasle，这时候就是百分之75，因为他这时候就考虑子熔断器的内存限制了，所以其实没那么大了，阈值就低了一些。可以理解。

2、字段熔断器(fielddata circuit breaker)

字段数据断路器估计将字段加载到字段数据缓存中所需的堆内存。如果加载字段将导致高速缓存超过预定义的内存限制，则断路器将停止操作并返回错误。

这个机制主要针对我们的fielddata，我们在es中经常会对字段做聚合，做排序，但是你做聚合排序这类操作是不能对text类型的字段做的，因为大多数字段可以将索引时生产的磁盘 doc_values 用于此数据访问模式，但是文本（text）字段不支持 doc_values。所以我们需要一种替代方案，文本（text）字段使用查询时内存中的数据结构，称为 fielddata。当我们首次将该字段用于聚合，排序或在脚本中使用时，将按需构建此数据结构（懒加载的）。它是通过从磁盘读取每个段的整个反向索引，反转你的分词结果变成文档并将结果存储在 JVM 堆中的内存中来构建的。
Fielddata 会占用大量堆空间，尤其是在加载大量的文本字段时。一旦将字段数据加载到堆中，它在该段的生命周期内将一直保留在那里，他无法被gc回收。同样，加载字段数据是一个昂贵的过程，可能导致用户遇到延迟的情况。这就是默认情况下禁用字段数据的原因。这个机制默认是关闭的。

字段熔断器可使用以下设置进行配置：

indices.breaker.fielddata.limit：
这个限制默认为 JVM 堆的 40%。也就是说我们每次处理fielddata加载的时候都会判断是不是触发了该限制，如果超出限制，就触发熔断。
indices.breaker.fielddata.overhead：
估算因子，在计算内存是需要与估算因子相乘得到内存估算值。默认1.03，是一个系数，也不是直接内存到了百分之40就熔断，而是要乘以这个系数，不过1.03和不乘也差不多。反正你自己计算的时候估计量的时候，最好计算上，比较精准。

这两个配置，均为动态配置，你可以随时使用命令修改。

3、请求熔断器(request circuit breaker)

请求熔断器使 Elasticsearch 可以防止每个请求的数据结构（例如，用于在请求期间计算聚合的内存）超过一定数量的内存。我说直接一点就是他是限制你每次请求的大小的，比如这个限制是5m，那每次请求不能超过这个值，各自请求是独立的。

请求熔断器可使用以下设置进行配置：

indices.breaker.request.limit：
请求中断器的限制，默认为 JVM 堆的 60%，也就是每次请求大小不能超过堆内存的60%，那你可能要问了，百分之六十这个比例那真不小，他们各个请求独立，都不能超过60，但是多个请求叠加起来，那完全有可能超过百分之百，直接干崩。假如你是个杠精，完全可以想到每个请求都占百分之59，这样没超了请求熔断，但是两个加起来就干一百多了，这时候不是崩了？你es连两个请求都容不下我，那你玩毛。你不要忘了，我们还有父级熔断器在呢，你虽然没超请求熔断，但是父级熔断也会给你限制住。别想卡bug。
indices.breaker.request.overhead：
一个常量，所有请求估计值都与该常量相乘以确定最终估计值。默认值为 1。

以上配置均为动态配置。

4、进行中的请求熔路器(In flight requests circuit breaker)

进行中的请求熔路器使 ES 可以限制 transport 或 HTTP 级别上所有当前活动的即将传入请求的内存使用，使其不超过节点上的一定内存量。内存使用情况取决于请求本身的内容长度。该断路器还认为，不仅需要内存来表示原始请求，而且还需要将其作为结构化对象，这由默认开销反映出来。
这个熔断器其实用的不多。

network.breaker.inflight_requests.limit
正在进行的请求熔断器的限制，默认为 JVM 堆的 100%。这意味着它受为父熔断器配置的限制的约束。因为受到父级熔断限制，其实这个一般不用配置。
network.breaker.inflight_requests.overhead
一个常数，所有飞行请求估计值都乘以确定最终估计值。默认值为 2。

以上均为动态配置。

5、脚本编译熔断器(Script compilation circuit breaker)

与之前的基于内存的断路器略有不同，脚本编译断路器限制了一段时间内内联脚本编译的次数。
关于如何使用es中的脚本我们可以参考脚本
他的配置很简单，就一个参数。

script.max_compilations_rate
该配置为动态配置，限制特定间隔内允许编译的唯一动态脚本的数量。默认为 150/5m，即每 5 分钟 150 次。

6、正则表达式熔断器(regex circuit breaker)

编写不当的正则表达式会降低集群稳定性，并且性能。正则表达式断路器限制了 Painless 脚本中的 regex 来获取。
该熔断器的配置如下：

script.painless.regex.enabled：

该配置为静态配置，在 Painless 脚本中启用正则表达式。可以配置三个值，分别为。limited （默认），true，false。

limited ：启用正则表达式，但使用 script.painless.regex.limit-factor 设置。这个配置为静态配置，限制 Painless 脚本中的正则表达式可以考虑的字符数。Elasticsearch 通过将设置值乘以脚本输入的字符长度来计算此限制。
例如，输入 foobarbaz 的字符长度为 9。如果 script.painless.regex.limit-factor 是 6，foobarbaz 上的正则表达式最多可以考虑 54 （9 * 6）个字符。如果表达式超过此限制，则它会触发 Regex 断路器并返回错误。

true：启用没有复杂度限制的正则表达式。禁用 regex 断路器。

false:禁用 regex。任何包含正则表达式的 Painless 脚本都会返回错误。

三、熔断器错误

1、熔断器错误的意义

我们知道了什么时候触发熔断，也知道了es 使用熔断器来防止节点耗尽 JVM 堆内存。如果 Elasticsearch 估计某个操作将超过熔断器，则会停止该操作并返回错误。
那么如果熔断了是什么表现呢，换言之我们如何知道，如何定位熔断。
默认情况下，父断路器在 JVM 内存使用率达到 95% 时触发。为防止错误，我们建议在你的服务使用率经常超过85%的时候就及时采取措施来减轻内存压力。或者优化内存，或者提高机器配置。

2、错误表现&&观察手段

如果请求触发了熔断器，Elasticsearch 将返回带有 429 HTTP 状态代码的错误。

{'error': {'type': 'circuit_breaking_exception','reason': '[parent] Data too large, data for [<http_request>] would be [123848638/118.1mb], which is larger than the limit of [123273216/117.5mb], real usage: [120182112/114.6mb], new bytes reserved: [3666526/3.4mb]','bytes_wanted': 123848638,'bytes_limit': 123273216,'durability': 'TRANSIENT'},'status': 429
}

Elasticsearch 还会将断路器错误写入 elasticsearch.log。当自动化过程（如分片的重分配等等）触发断路器时，这非常有用。

Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [num/numGB], which is larger than the limit of [num/numGB], usages [request=0/0b, fielddata=num/numKB, in_flight_requests=num/numGB, accounting=num/numGB]

此外你还可以及时检查 JVM 内存使用情况。如果您启用了堆栈监控，则可以在 Kibana 中查看 JVM 内存使用情况。在主菜单中，单击 Stack Monitoring。在堆栈监控概述上页面上，单击 Nodes （节点）。JVM Heap 列列出了每个节点的当前内存使用情况。
如果你没有开启监控，那你可以使用api来获取。

GET _cat/nodes?v=true&h=name,node*,heap*

要获取每个断路器的 JVM 内存使用情况，请使用节点统计 API 的 API 进行 API 的处理。

GET _nodes/stats/breaker

3、处理方法

3.1、内存监控

高 JVM 内存压力通常会导致断路器错误。看 JVM 内存压力高。

你可以使用命令来查看你的节点内存使用情况。

GET _nodes/stats?filter_path=nodes.*.jvm.mem.pools.old

然后来计算内存压力，如下所示：
JVM 内存压力 = used_in_bytes / max_in_bytes

3.2、gc日志

作为java开发的应用，你在做内存监控的时候，很难不使用gc日志。
随着内存使用量的增加，垃圾回收变得更加频繁，并且需要长。您可以在 elasticsearch.log. 例如，以下事件指出 Elasticsearch 在过去 40 秒内花费了超过 50%（21 秒）的时间执行垃圾回收。

[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s]

3.3、减少jvm占用

1、减少分片数量
每个分片都使用内存。在大多数情况下，一小部分大型分片使用较少的资源。有关减少分片计数的提示，请参阅分片减少
2、避免昂贵的搜索
昂贵的搜索可能会占用大量内存。为了更好地跟踪集群上昂贵的搜索，请启用慢日志。
昂贵的搜索可能具有较大的 size 参数，使用具有大量存储桶的聚合，或者包括昂贵的查询。为了防止昂贵的搜索，请考虑以下设置更改：
使用 index.max_result_window 索引设置。
使用 search.max_buckets 集群设置。
使用 search.allow_expensive_queries cluster 设置。

PUT _settings
{"index.max_result_window": 5000
}PUT _cluster/settings
{"persistent": {"search.max_buckets": 20000,"search.allow_expensive_queries": false}
}

es中认为的复杂检索

3.4、防止映射爆炸

定义过多的字段或嵌套字段太深可能会导致映射使用大量内存的爆炸。要防止映射爆炸，请使用 mapping limit 设置来限制字段映射的数量。

3.5、分散批量请求

虽然比单个请求更高效，但 bulk indexing 或者 multi-search请求仍会造成较高的 JVM 内存压力。如果可能，请提交较小的请求，并在请求之间留出更多时间。

3.6、避免在文本字段上使用 fielddata

对于高基数文本字段，fielddata 可以使用大量的 JVM 内存。为避免这种情况，Elasticsearch 默认在文本字段上禁用 fielddata。如果您已启用 fielddata 并触发了 fielddata 断路器，请考虑禁用它并改用关键字字段。请参阅 fielddata mapping 参数。
并且你还可以在触发了字段熔断器的时候清除他的缓存。

POST _cache/clear?fielddata=true

3.7、升级节点内存

加机器永远是最稳的。

四、内存部分

ES使用的JVM内存的中存在几大类无法GC的缓存

1、内存占用

1.1、QueryCache：

支持调用API进行清理。实现类org.elasticsearch.indices.IndicesQueryCache
查询缓存负责缓存查询结果。每个节点有一个查询缓存，由所有分片共享。查询缓存只缓存在过滤器上下文中使用的查询，即用来缓存filter查询。
以下设置是静态的，必须在群集中的每个数据节点elasticsearch.yml上配置：
indices.queries.cache.size：默认10%。

以下设置是静态的，索引级别
index.queries.cache.enabled：是否对某个索引开启查询缓存，默认true。创建索引时配置settings中。

1.2、RequestCache：

支持调用API进行清理。实现类org.elasticsearch.indices.IndicesRequestCache
分片级请求缓存模块在每个分片上缓存本地结果。这使得频繁使用的搜索请求（可能很繁重）几乎能立即返回结果。请求缓存非常适合日志场景，在日志场景中，只有最新的索引会被主动更新，而较早索引的结果将直接从缓存中提供。
以下设置是静态的，必须在群集中的每个节点elasticsearch.yml上配置：
indices.requests.cache.size: 默认1%

以下设置是索引分片级别
index.requests.cache.enable：开启true，关闭false，创建索引时配置settings中。

1.3、FieldDataCache：

支持调用API进行清理。
实现类org.elasticsearch.indices.fielddata.cache.IndicesFieldDataCache
字段数据缓存主要用于对字段进行排序或计算聚合。它将所有字段值加载到内存中，以便基于文档快速访问这些值。为一个字段建立字段数据缓存的成本可能很高，因此建议有足够的内存来分配它，并保持它处于加载状态。
indices.fielddata.cache.size：默认无界，属于静态配置。

1.4、SegmentsCache：

不支持调用API进行清理。
Lucene的segment需要加载到JVM的内存，从ES7（Lucene）已经换成堆外内存的方式实现。

1.5、indexing-buffer：

索引缓冲区用于存储新索引的文档。当缓冲区满时，缓冲区中的文档就会被写入磁盘上的一个区段。节点上的所有分片共享这个缓冲区。

以下设置是静态的，必须在群集中的每个数据节点上配置：
indices.memory.index_buffer_size：可以配置成百分比或字节大小值的形式。默认值为 10%，这意味着分配给节点的堆总量的 10%将用作所有分片共享的索引缓冲区大小。
indices.memory.min_index_buffer_size：当 index_buffer_size 指定为百分比，则可以使用此设置指定绝对最小值。默认值为 48MB。
indices.memory.max_index_buffer_size：如果 index_buffer_size 指定为百分比，则可以使用此设置指定绝对最大值。默认值为无限制。

2、清理api

清除缓存API:

# 按照索引粒度清除缓存
POST /twitter/_cache/clear
POST /kimchy,elasticsearch/_cache/clear
# 清除所有索引的缓存
POST /_cache/clear

查询节点的部分内存使用情况和缓存命中情况:

GET _cat/nodes?h=name,*heap*,*memory*,*Cache*&format=json

查询某个索引部分内存占用情况:

GET _cat/indices/twitter?h=*memory*&format=jsonGET _cat/indices/?s=segmentsMemory:desc&v&h=index,segmentsCount,segmentsMemory,memoryTotal,mergesCurrent,mergesCurrentDocs,storeSizeGET _cat/segments/twitter?v

查询节点的熔断状况：

GET _nodes/stats/breaker

在业务使用了别名或跨索引查询时，实际查询的索引数量过大，查询高峰期时，父熔断器没能敏捷的触发熔断限流，导致节点JVM出现OOM，最终节点挂掉不可用。
可以适当调整熔断器的熔断值，减少熔断触发比例,但是这种总归不是办法，如果你的版本比较低，可能存在实现问题，7版本之前的实现无法感知及时，进而触发父熔断。
为了增加父熔断器的触发灵敏度，ES7重新实现了触发校验，使用JDK自带的MemoryMXBean，几乎实时获取到内存的实际使用量，来进行校验判断

MemoryMXBean MEMORY_MX_BEAN = ManagementFactory.getMemoryMXBean();
return MEMORY_MX_BEAN.getHeapMemoryUsage().getUsed();

五、源码解读

我们来分析一下源码关于熔断器的实现。本文所有内容均基于es7.17.7
在我们开始分析之前，我们先来聊一个逻辑，这个逻辑曾经在说springmvc的时候提到过。我们拿到一个源码，在你没有头绪的时候如何开始。比如我们这个例子，我们是分析熔断器的，那么熔断器是啥时候加载的呢，这个很重要。肯定是服务启动的时候，他就被启动了，或者初始化了，或者注册了反正就是他开始了，那么我们其实应该第一就是去看集群启动的地方，而集群是一个一个的节点组成的。所以我们应该关注的是Node类。看看他有没有这个熔断器。

当然，你会觉得这很上帝视角，实际上我从0开始定位熔断器的源码的时候。我首先找到的是org.elasticsearch.common.breaker.CircuitBreaker这个接口，然后一步一步根据在哪里使用了这个接口或者他的实现类，或者他的一些属性来追踪的。这个第一次来百分之五十可能要靠运气和猜测了，猜测也不是瞎猜，这种大型成熟组件命名是很考究的，多数讲究见名知意，所以可以适当看看命名。

好了，我们来看Node类。
首先，当一个节点node启动的时候，在org.elasticsearch.node.Node类中初始化了一个熔断器实现

final CircuitBreakerService circuitBreakerService = createCircuitBreakerService(settingsModule.getSettings(),pluginCircuitBreakers,settingsModule.getClusterSettings());其中circuitBreakerService实现为：public static CircuitBreakerService createCircuitBreakerService(Settings settings,List<BreakerSettings> breakerSettings,ClusterSettings clusterSettings
) {// 默认为hierarchyString type = BREAKER_TYPE_KEY.get(settings);if (type.equals("hierarchy")) {// 默认返回return new HierarchyCircuitBreakerService(settings, breakerSettings, clusterSettings);} else if (type.equals("none")) {return new NoneCircuitBreakerService();} else {throw new IllegalArgumentException("Unknown circuit breaker type [" + type + "]");}
}

所以我们看到他在node节点中初始化了HierarchyCircuitBreakerService这个组件，于是我们就来到HierarchyCircuitBreakerService这个里面。

我们来到org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService这个类里面看一下。
这个类非常庞大，很多地方声明了一些配置的初始化值，我们只看核心逻辑，不要被那些细节逻辑卡住。
我们就看父级熔断器和请求熔断器相关的，在一开始他初始化了一个配置。就是关于这两个熔断器的。

public static final Setting<Boolean> USE_REAL_MEMORY_USAGE_SETTING = Setting.boolSetting("indices.breaker.total.use_real_memory",true,Property.NodeScope
);public static final Setting<ByteSizeValue> TOTAL_CIRCUIT_BREAKER_LIMIT_SETTING = Setting.memorySizeSetting("indices.breaker.total.limit",settings -> {if (USE_REAL_MEMORY_USAGE_SETTING.get(settings)) {return "95%";} else {return "70%";}},Property.Dynamic,Property.NodeScope
);public static final Setting<ByteSizeValue> REQUEST_CIRCUIT_BREAKER_LIMIT_SETTING = Setting.memorySizeSetting("indices.breaker.request.limit","60%",Property.Dynamic,Property.NodeScope
);
public static final Setting<Double> REQUEST_CIRCUIT_BREAKER_OVERHEAD_SETTING = Setting.doubleSetting("indices.breaker.request.overhead",1.0d,0.0d,Property.Dynamic,Property.NodeScope
);

如果你还记得上面的配置，你就会发现它其实就是把这些默认值加载进来了，当然你要是用api动态修改动态属性，这里的值都会变。他会提供api来处理。
我们看到他有个map，breakers，
private final Map<String, CircuitBreaker> breakers;这个map中存储着所有的子级熔断器，其中key为熔断器的名称。我们这里看请求熔断器，自然就是CircuitBreaker.REQUEST = “request”,value就是CircuitBreaker这个接口，这里要注意一点，所有的子熔断器都是CircuitBreaker。只不过不同名字而已。他们的落脚点没有区别。

// 所有的子熔断器都被这个方法包装，你能看到他其实就是ChildMemoryCircuitBreaker，因为我们
// 一般不用Noop,noop这个啥也不做，我们不分析他。不要被细节卡住。
private CircuitBreaker validateAndCreateBreaker(BreakerSettings breakerSettings) {// Validate the settingsvalidateSettings(new BreakerSettings[] { breakerSettings });return breakerSettings.getType() == CircuitBreaker.Type.NOOP? new NoopCircuitBreaker(breakerSettings.getName()): new ChildMemoryCircuitBreaker(breakerSettings,LogManager.getLogger(CHILD_LOGGER_PREFIX + breakerSettings.getName()),this,breakerSettings.getName());
}

所以我们简单分析之后可以知道，所有的子熔断都最后是一个ChildMemoryCircuitBreaker。
而父熔断器没有被放到这个map中，他是被保存在了
private volatile BreakerSettings parentSettings;这个变量中，之所以加volatile是因为可能多个并发用api在修改他的动态配置。
好了，我们继续往下走。
我们现在得到一点就是所有的子熔断都最后是一个ChildMemoryCircuitBreaker，并且都被存在了breakers这个map中，而父级熔断器被放在了 BreakerSettings parentSettings

所以我们现在确定了子熔断器的逻辑都在ChildMemoryCircuitBreaker了，那我们就来看看org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker这个类。

/** Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one* or more contributor license agreements. Licensed under the Elastic License* 2.0 and the Server Side Public License, v 1; you may not use this file except* in compliance with, at your election, the Elastic License 2.0 or the Server* Side Public License, v 1.*/package org.elasticsearch.common.breaker;import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.message.ParameterizedMessage;
import org.elasticsearch.common.unit.ByteSizeValue;
import org.elasticsearch.indices.breaker.BreakerSettings;
import org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService;import java.util.concurrent.atomic.AtomicLong;/*** Breaker that will check a parent's when incrementing*/
public class ChildMemoryCircuitBreaker implements CircuitBreaker {private volatile LimitAndOverhead limitAndOverhead;private final Durability durability;private final AtomicLong used;private final AtomicLong trippedCount;private final Logger logger;private final HierarchyCircuitBreakerService parent;private final String name;/*** fieldName:就是你熔断器的名称* bytesNeeded：就是触发熔断时候的内存* 所以我们看到这个方法是统一封装了一个异常信息构建，通过熔断器名称区别。*/@Overridepublic void circuitBreak(String fieldName, long bytesNeeded) {final long memoryBytesLimit = this.limitAndOverhead.limit;this.trippedCount.incrementAndGet();final String message = "["+ this.name+ "] Data too large, data for ["+ fieldName+ "]"+ " would be ["+ bytesNeeded+ "/"+ new ByteSizeValue(bytesNeeded)+ "]"+ ", which is larger than the limit of ["+ memoryBytesLimit+ "/"+ new ByteSizeValue(memoryBytesLimit)+ "]";logger.debug(() -> new ParameterizedMessage("{}", message));throw new CircuitBreakingException(message, bytesNeeded, memoryBytesLimit, durability);}/*** 这里就是做熔断计算的地方，判断你是不是要熔断了* bytes:申请的大小* lable:熔断器的名称*/@Overridepublic void addEstimateBytesAndMaybeBreak(long bytes, String label) throws CircuitBreakingException {final LimitAndOverhead limitAndOverhead = this.limitAndOverhead;final long memoryBytesLimit = limitAndOverhead.limit;final double overheadConstant = limitAndOverhead.overhead;// short-circuit on no data allowed, immediately throwing an exception// 配置为0，立刻触发熔断。if (memoryBytesLimit == 0) {circuitBreak(label, bytes);}long newUsed;// 如果你配置了-1，那就无限制，打印一句警告日志if (memoryBytesLimit == -1) {newUsed = noLimit(bytes, label);} else {/*** 这里就是正常的配置那种，既不是不限制，也不是无限制，这里会判断你的当前使用大小* 和你配置的阈值，如果触发了就进入circuitBreak()发生熔断，否则就更新一下当前的* 占用量(cas更新，因为多个请求)。这里我们看到其实就是* memoryBytesLimit > 0 && newUsedWithOverhead > memoryBytesLimit* 来判断是否熔断了，所以这里其实就是子熔断器的进入地方。*/newUsed = limit(bytes, label, overheadConstant, memoryBytesLimit);}/*** 当你走到这里还没抛出熔断异常的时候，那就是子熔断器都过去了，此时我们要判断父熔断器。* 还记得我们上面说的，子熔断器是封装在ChildMemoryCircuitBreaker中的，而父熔断器就是在* org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService* 这个里面的parentSettings中，所以这里我不用看也知道checkParentLimit是跳到* HierarchyCircuitBreakerService中了。*/try {parent.checkParentLimit((long) (bytes * overheadConstant), label);} catch (CircuitBreakingException e) {// If the parent breaker is tripped, this breaker has to be// adjusted back down because the allocation is "blocked" but the// breaker has already been incrementedthis.addWithoutBreaking(-bytes);throw e;}assert newUsed >= 0 : "Used bytes: [" + newUsed + "] must be >= 0";}......
}

我们就接着父熔断器的跳入来看org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService#checkParentLimit

public void checkParentLimit(long newBytesReserved, String label) throws CircuitBreakingException {// 父级熔断器判断的不是请求申请或者分配，看的是总的堆占用final MemoryUsage memoryUsed = memoryUsed(newBytesReserved);// 父熔断器的配置限制long parentLimit = this.parentSettings.getLimit();// 做判断检查，是不是超过了配置if (memoryUsed.totalUsage > parentLimit && overLimitStrategy.overLimit(memoryUsed).totalUsage > parentLimit) {this.parentTripCount.incrementAndGet();final String messageString = buildParentTripMessage(newBytesReserved,label,memoryUsed,parentLimit,this.trackRealMemoryUsage,this.breakers);// 根据策略检查是不是要看子熔断器的占用。默认是需要的。// derive durability of a tripped parent breaker depending on whether the majority of memory tracked by// child circuit breakers is categorized as transient or permanent.CircuitBreaker.Durability durability = memoryUsed.transientChildUsage >= memoryUsed.permanentChildUsage? CircuitBreaker.Durability.TRANSIENT: CircuitBreaker.Durability.PERMANENT;logger.debug(() -> new ParameterizedMessage("{}", messageString));throw new CircuitBreakingException(messageString, memoryUsed.totalUsage, parentLimit, durability);}
}

所以这就是熔断器的源码脉络分析。那么还有一个问题就是他在哪触发的呢，我们就知道他是咋工作的，不知道他在哪里工作的，你可以用idea的功能点中看看哪里用了，我可以告诉你他实现的很笨。他真的是代码埋点。
也就是你每次请求比如你做了一次聚合，这个聚合请求在发起的时候会包装一个断路器，然后请求的时候在代码里面判断。其实我想着是不是可以做成类似aop的模式，不需要这么做。我就不去跟源码了，我们用一个测试用例看一下org.elasticsearch.search.aggregations.support.AggregationContext

这个类在初始化的时候，包装了断路器，

MultiBucketConsumer consumer = new MultiBucketConsumer(maxBucket, breakerService.getBreaker(CircuitBreaker.REQUEST));

最后在一步一步往下查的时候，查完了就会根据断路器分析这次的占用是不是要熔断了。