Support LRU evicting mechanism for origin statistic map in StatisticNode

[yikangfeng]

Issue Description

Type: feature request

Describe what happened (or what feature you want)

我们的业务场景，希望能能够按照调用方的IP来限流，Sentinel 目前支持按照调用源来限流，但是没有淘汰策略，业务真正使用起来，假如IP数量比较多，风险有点大，所以希望能够支持LRU，业务使用起来更稳定。

其实热点参数限流，目前是支持LRU的，但是为什么不能用热点参数来限流呢？
热点参数限流，一般情况下，需要把限流的源绑定到参数上，这样才可以使用。但是实际的业务场景很复杂，例如上游服务不愿意改动，所以用热点参数限流可能做起来就不是那么的方便。所以才需要能够按照调用源来限流。例如按IP，这样只需要获取到上游服务的IP就行，并且IP过多的情况下，还支持LRU，就比较稳妥了。

Describe what you expected to happen

How to reproduce it (as minimally and precisely as possible)

Tell us your environment

Anything else we need to know?

[sentinel-bot]

Hi @yikangfeng, we detect non-English characters in the issue. This comment is an auto translation from @sentinel-bot to help other users to understand this issue.
We encourage you to describe your issue in English which is more friendly to other users.

According to the caller to limit the flow, I hope to support the LRU, which can flexibly support the current limit by various sources, without worrying about memory problems.

Issue Description

Type: feature request

Describe what happened (or what feature you want)

In our business scenario, we hope to be able to limit traffic according to the IP of the caller. Sentinel currently supports traffic limiting according to the calling source, but there is no elimination strategy. The service is actually used. If the number of IPs is large, the risk is a bit large, so I hope to be able to Support LRU, the business is more stable to use.

Describe what you expected to happen

How to reproduce it (as minimally and precisely as possible)

Tell us your environment

Anything else we need to know?

[sczyh30]

This could bring extra dependencies (e.g. ConcurrentLinkedHashMap), but it's might be necessary for some circumstances.

What do you think of it? @CarpenterLee @jasonjoo2010 @cdfive

[ctrl2]

这个功能什么时候能够合并到主版本？非常有用！