Hazelcast在openLooKeng中的应用（Cache篇）

openLooKeng，Make Big Data Simplified

openLooKeng是一款开源的高效数据虚拟化分析引擎。在使用openLooKeng过程中，社区一小伙伴遇到数据查询存在不同步的问题；对此，该小伙伴非常给力，向社区提供了解决方案。我们非常感谢他的支持，也希望本篇博客对其他小伙伴有帮助。

欢迎访问openLooKeng官网
https://openlookeng.io

社区代码仓
https://gitee.com/openlookeng

本期分享

问题

openLooKeng的查询存在不同步的问题，现在需要解决这个问题。

经过分析，查询读的是Cache。在AA模式（Active/Active Mode）下，一个节点修改了Metastore ，另外一个节点不会得到通知，所以不会使缓存失效。问题出现在AA模式下缓存不同步的问题。

解决办法

目前openLooKeng的缓存模式只有Guava。
在异步的时候存在数据不同步的问题。解决办法：

1. 使用redis，redis作为分布式缓存是相当优秀。支持很多数据类型，支持cluster模式。但是这个方法会引入新的技术，会让部署困难。最小化部署，尽量不引入第三方依赖服务；
2. 考虑到服务已经有Hazelcast了，可以考虑用Hazelcast作为缓存来使用。(注 其实还有一种方案，让 Hazelcast作为广播用，当发生更新数据的时候，同时通知两个节点的Cache失效) 现在采用Hazelcast作为分布式缓存，同时保留以前的Guava缓存。

两套缓存可以让用户选择，一个是local的，一个是distributed；架构模式如下：

读写策略模式如下：

Cache Aside Pattern，Delete the existing Cache when writing the database。Cache Aside Pattern能有效避免并发问题。

Cache Aside的优点:
当写操作发生时，假设淘汰缓存作为对缓存通用的处理方式，又面临两种抉择：
（1）先写数据库，再淘汰缓存
（2）先淘汰缓存，再写数据库

我们假设：两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。所以这个设计是错误的，不建议使用。

一个是查询操作，一个是更新操作的并发，首先，没有了删除Cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。

Hazelcast 学习

Hazelcast作为一个分布式机制，可以用Hazelcast的Imap作为分布式缓存。
这里需要注意的是由于Hetumetastore存储有六个缓存，需要对每个缓存实例化。不能用一套。

IMap<Integer, List<String>> clusterMap1 = instance.getMap("MyMap1");
IMap<Integer, List<String>> clusterMap2 = instance.getMap