Hazelcast源码剖析之Eviction

1 奇怪的现象

在使用HazelcastEviction时,发现观察到的现象与想象的不同。按照官方文档介绍,Eviction有这样几个配置选项:

<hazelcast>

  <map name="default">

    ...

    <time-to-live-seconds>0</time-to-live-seconds>

    <max-idle-seconds>0</max-idle-seconds>

    <eviction-policy>LRU</eviction-policy>

    <max-size policy="PER_NODE">5000</max-size>

    <eviction-percentage>25</eviction-percentage>

    ...

  </map>

</hazelcast>

看后三项,按照参数的描述应为:当每个结点的entry数达到5000时,使用LRU策略,剔除25%entry,即1250个。可是观察到的现象一般是entry数达到4200左右就止步不前,继续大量高并发的insert测试,既不会增长也不会减少。这是怎么回事?而且相比RedisHazelcast在达到eviction临界条件后继续并发插入和读写时,性能表现依旧良好,就像没有发生eviction一样。是使用了多线程还是什么神奇的算法?源码之前,了无秘密,还是从代码中寻找答案吧。

2 代码剖析

我们客户端使用的,也是最顶层的API,就是IMap了,这里以比put()更为高效的set()作为分析的起点。后面其实能够看到,因为使用了命令模式(command),两者都是继承一个父类,evict都是在一个地方触发的。

2.1 MapProxyImpl包装器

IMap的直接实现类是MapProxyImpl,但它只是个Wrapper,负责转换keyvalue

Hazelcast源码剖析之Eviction_第1张图片

2.2 MapProxySupport封装命令对象

真正的实现都是在它继承的MapProxySupport类中,例如set()调用的setInternal()就能在Support类中找到。各种internal方法将操作包装成Operation类,这方便了远程调用的实现,例如set()要执行的结点不在本地。

Hazelcast源码剖析之Eviction_第2张图片

2.3 SetOperation命令模式

invokeOperation()中会确定操作应该在哪个分区执行,这个分区位于哪个结点上。这里Hazelcast维护了一个线程池,每个分区都有对应的线程去执行本分区的操作。因为过程比较复杂,所以这里直接略过,继续关注我们重点想知道的eviction过程的实现。那么直接看一下SetOperation中的逻辑。SetOperation很简单,直接调用RecordStore保存键值对,但afterRun()中有一些隐含的后处理。

Hazelcast源码剖析之Eviction_第3张图片

2.4 BasePutOperation触发eviction

果然,在afterRun()中除了广播事件、使Near缓存失效外,还有触发eviction过程。Evict()调用的就是RecordStoreevictEntries()方法。

Hazelcast源码剖析之Eviction_第4张图片

2.5 AbstractEvictableRecordStore控制eviction

真正的evict控制逻辑就在这里。首先,shouldEvict()会判断是否满足了我们之前配置的eviction的触发条件,如PER_NODE=5000。如果满足则调用removeEvictableRecords()开始剔除数据。

Hazelcast源码剖析之Eviction_第5张图片

2.6 EvictionOperator事有蹊跷

最终removeEvictableRecords调用的是EvictionOperator,具体的实现都在这里。但仔细看这段代码却看不出有什么高明之处,只是简单地迭代RecordStore的记录,将满足条件的entry剔除掉。既没用多线程,也没什么特殊的算法,这到底是怎么回事?

Hazelcast源码剖析之Eviction_第6张图片

2.7 答案揭晓

谜底其实就在Operation类对应的RecordStore初始化上。我们知道,默认情况下,Hazelcastmap分为271partition。其实RecordStore也是按这些partition划分的,而不是使用一个大的RecordStore。所以从BasePutOperationevict()到后续处理的都只是当前key对应分区的RecordStore。也就是说:当key要被处理时,Eviction发生在对应的partition,而不会evict所有数据的25%Redis就是处理database中的所有数据,所以延迟会有所增加)。所以,当我们继续压力测试时,不断有key继续插入,这些分区就会不断发生eviction,导致整体的内存使用会保持不变。

Hazelcast源码剖析之Eviction_第7张图片

3 类图全貌

梳理了上面的执行流程后,我们最后整理一下这些类之间的关系。

Hazelcast源码剖析之Eviction_第8张图片

 

你可能感兴趣的:(Hazelcast源码剖析之Eviction)