Open zhangjunjia opened 4 years ago
现工作负责的一个datanode项目，其本质是一个巨大的分布式hashmap。其含有亿级别的key，value则是用户信息UserInfo。通过hash将该巨大的hashmap分成了多个partition，然后分布到50多台机器上，即每台机器有1至3个partition。partition的数据存放于机器上datanode进程的Java Heap中，这有几个好处：
但这也带来了一些坏处：
上一篇文章浅谈有状态Java服务热部署方案探讨了解决这个问题的一些方案，本文继续讨论此问题——将Java Heap做offload的方案。
chronicle-map是Chronicle Software公司开源的一款堆外hashmap，它支持两种内存模式：
/dev/shm/
第二种模式显然比较适合做Java Heap的offload。但对我们的datanode业务而言，Chronicle-Map存在着几个问题：
int[]
float[]
String[]
其实第一个问题也不是不能规避。我们可以自行维护一套内存地址到Java数据结构（UserInfo）的映射关系，在访问第N个属性时再去按需反序列化该属性。但这样又带了新问题，按下葫芦浮起瓢：
综上，chronicle-map虽然好但不适合我们。
Apache Ignite® is a horizontally scalable, fault-tolerant distributed in-memory computing platform for building real-time applications that can process terabytes of data with in-memory speed.
ignite是apache顶级项目之一，上文是其官方定义，它可以和以下应用扮演同样角色：
ignite支持以下几种模式：
ignite还有其他强大的特性：
总的来讲，ignite非常强悍而且功能特性非常的多，且有很多production上应用的示例。但ignite的以下几点不符合我方的业务需求：
现工作负责的一个datanode项目，其本质是一个巨大的分布式hashmap。其含有亿级别的key，value则是用户信息UserInfo。通过hash将该巨大的hashmap分成了多个partition，然后分布到50多台机器上，即每台机器有1至3个partition。partition的数据存放于机器上datanode进程的Java Heap中，这有几个好处：
但这也带来了一些坏处：
上一篇文章浅谈有状态Java服务热部署方案探讨了解决这个问题的一些方案，本文继续讨论此问题——将Java Heap做offload的方案。
chronicle-map
chronicle-map是Chronicle Software公司开源的一款堆外hashmap，它支持两种内存模式：
/dev/shm/），JVM进程退出了数据还在；第二种模式显然比较适合做Java Heap的offload。但对我们的datanode业务而言，Chronicle-Map存在着几个问题：
int[]、float[]、String[]对象，长度有非常大的不确定性，因此无法使用其建议的ValueType数据类型。因此我方业务只能使用实现其建议的ByteReader/ByteWriter接口写自定义数据序列化/反序列化操作，序列化开销对于我方业务频繁需要遍历几百万个Key的场景是无法接受的。其实第一个问题也不是不能规避。我们可以自行维护一套内存地址到Java数据结构（UserInfo）的映射关系，在访问第N个属性时再去按需反序列化该属性。但这样又带了新问题，按下葫芦浮起瓢：
综上，chronicle-map虽然好但不适合我们。
apache ignite
ignite是apache顶级项目之一，上文是其官方定义，它可以和以下应用扮演同样角色：
ignite支持以下几种模式：
ignite还有其他强大的特性：
总的来讲，ignite非常强悍而且功能特性非常的多，且有很多production上应用的示例。但ignite的以下几点不符合我方的业务需求：