在MapStore实现中重用Hazelcast序列化逻辑

Question

我已经使用IdentifiedDataSerializable为我的POJO实现了一个自定义序列化程序，以便随着类的发展和需要添加/删除新字段，我可以维护一个细粒度的控件。对于某些集合，我还需要持久化，并使用嵌入式键值存储实现了MapStore。我的问题是，我希望在IdentifiedDataSerializable实现中重用MapStore序列化，利用代码重用以及确保类在未来的进化。

我试图获得对内部Hazelcast SerializationService的引用，但通过HazelcastInstance中的“公共”API并不容易获得。事实上，我想不出有什么像样的方法来抓住它。

实际上，我想要的是MapStore接口的一个版本，它可以在字节数组级别上工作，在调用之前，Hazelcast将处理序列化/反序列化。新的特征请求我想..。

同时，任何如何解决这个问题的想法都是值得欢迎的。

Answer 1

把你的问题分为两部分：

1. 如何避免为Hazelcast和持久存储维护不同的序列化行为。
2. 如何避免在Hazelcast机器和持久化机器之间执行额外的序列化反序列化步骤的开销。

第一部分：

我在使用杰克逊时已经取得了很好的效果，无论是在Hazelcast序列化方面还是在实现MapStore所需的持久性方面。这使我可以始终如一地使用相同的序列化逻辑，而不必担心不同设置的不同语义。

Fuad Malikov的博客文章比较了各种类型的Hazelcast序列化，并举例说明了如何使用Jackson二进制序列化。您可以在MapStore实现中使用相同的逻辑。更好的是，您可以使用不同的ObjectMapper来编写JSON，而不是二进制微笑格式--在其他方面，序列化语义是相同的，但是二进制格式更紧凑，读写速度更快，这就是哈泽尔广播所需要的。我发现能够在持久化存储中持久化人类可读的数据非常有用，对此我不太关心空间和时间效率，而更关心可维护性。(实际上，我已经能够通过编辑原始的JSON来“修补”生产中的数据，而不是我曾经考虑用二进制格式做的事情！)

Jackson在添加和删除字段时非常灵活，这得益于它的@JsonAnyGetter和@JsonAnySetter注释，它们允许您优雅地处理未识别的字段。

还有将序列化行为“注入”到您无法控制的类中的能力。

第二部分：

正如您已经注意到的，Hazelcast不支持只以序列化形式工作的MapStore变体，因此每个加载都涉及反序列化，然后是对Hazelcast结构的序列化。根据我的经验和阅读，高度优化的序列化库(如Jackson和克里奥 )速度如此之快，以至于额外的工作完全取决于从持久存储中读取的成本。

如果这对您来说足够重要以避免这一额外的步骤，您可以使用MapInterceptors在IMap<String, byte[]>上执行interceptGet中的反序列化和在interceptPut中的序列化。不过，我不推荐这样做，因为您会继续重新创建Hazelcast提供的即时功能。