Hazelcast源码剖析之Eviction

v:* { }
o:* { }
w:* { }
.shape { }p.MsoNormal,li.MsoNormal,div.MsoNormal { margin: 0cm; margin-bottom: .0001pt; text-align: justify; font-size: 10.5pt; font-family: "Calibri", "sans-serif" }
h2 { margin-top: 13.0pt; margin-right: 0cm; margin-bottom: 13.0pt; margin-left: 0cm; text-align: justify; line-height: 173%; page-break-after: avoid; font-size: 16.0pt; font-family: "Calibri Light", "sans-serif" }
h3 { margin-top: 13.0pt; margin-right: 0cm; margin-bottom: 13.0pt; margin-left: 0cm; text-align: justify; line-height: 173%; page-break-after: avoid; font-size: 16.0pt; font-family: "Calibri", "sans-serif" }
span.tag { }
span.1
{ }
span.attribute { }
span.value { }
span.2Char
{ font-family: "Calibri Light", "sans-serif"; font-weight: bold }
span.3Char
{ font-weight: bold }
.MsoChpDefault { font-family: "Calibri", "sans-serif" }
div.WordSection1 { }table.MsoNormalTable { font-size: 10.5pt; font-family: "Calibri", "sans-serif" }

1 奇怪的现象

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

...

<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测试，既不会增长也不会减少。这是怎么回事？而且相比Redis，Hazelcast在达到eviction临界条件后继续并发插入和读写时，性能表现依旧良好，就像没有发生eviction一样。是使用了多线程还是什么神奇的算法？源码之前，了无秘密，还是从代码中寻找答案吧。

2 代码剖析

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

2.1 MapProxyImpl包装器

IMap的直接实现类是MapProxyImpl，但它只是个Wrapper，负责转换key和value。

2.2 MapProxySupport封装命令对象

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

2.3 SetOperation命令模式

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

2.4 BasePutOperation触发eviction

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

2.5 AbstractEvictableRecordStore控制eviction

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

2.6 EvictionOperator事有蹊跷

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

2.7 答案揭晓

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

3 类图全貌

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