Adol1111

@cdfive > 是Dubbo服务用的sentinel-dubbo-adapter吗 是公司内部的RPC框架，不过是参考sentinel-dubbo-adapter写的，resourcename和dubbo差不多，也是分了 interfaceResourceName 和 methodResourceName > 这个社区有同学提到过，可参考 #2169 * 这个应该还没有实现吧。如果过滤resourceName，确实会看不到资源的调用情况。 * 但按照我描述的方案，如果OUT类型不创建origin统计，应该也可以有效降低内存。目前看ContextUtil.enter设置的origin是一个全局变量，会影响所有调用ContextUtil.enter(resourceName, origin) 以后的entry，直到ContextUtil.exit()。如果只是区分来源的话，对于OUT的场景，是否真的有必要也读取这个origin？

> 你是不是在B->redis的时候也调用了ContextUtil.enter(resourceName, origin);？所以产生了新的origin。 这个目前没有，只有在provider的时候设置了enter。不过我查了一下，唯一的不同是，设置 `ContextUtil.enter(resourceName, origin); `的resourceName，是一个固定值，而dubbo是根据methodResourceName变化的，不知道是否和这个有关系。 > 接着B作为consumer端调redis的时候，也就是OUT的场景，在SentinelDubboConsumerFilter里并没有调ContextUtil.enter产生新的origin，即复用当前的context，origin还是A origin确实是A，但是B作为consumer调用其他资源，应该不会经过SentinelDubboConsumerFilter吧？我是这样做的，这里没有额外设置ContextUtil.enter ``` // 这里通过rpc调用bizMethod，rpc的provider的filter中加入了 ContextUtil.enter void bizMethod() { redisClient.get("test:123", value); } ``` redisClient中 ``` Entry entry1 = null; Entry entry2 =...

> * ClusterBuilderSlot：首先根据 resourceName 创建 ClusterNode，并且 set clusterNode to defaultNode；然后再根据 origin 创建来源节点（类型为 StatisticNode），并且 set originNode to curEntry。 > * 来源节点（类型为 StatisticNode）的维度是 resource * origin，存在每个 ClusterNode 的 originCountMap 里面 所以StatisticNode数量确实会随着origin增加而增加，而且没有区分resource类型IN和OUT，如果是OUT类型，也会区分origin。导致统计的指标过多 @cdfive...

@lazyfighter redisName 和 key的数量排查过，所有resource合计没有超过100种。但是dump的数据里，metricNode的数量比其他数据高出好几十倍。唯一的变化就是redis接入了Sentinel，接入前的gc频率明显低于接入后的情况。 

The format of operationId can be changed like this, the first one is set as operationId, and the rest are set as operationId_method_path

This seems to be an unsolvable problem, unless we don't use additional_bindings, or there could be another field to be used as method name