【问题标题】:JGroups ReplicatedHashMap in a cluster集群中的 JGroups ReplicatedHashMap
【发布时间】:2019-01-21 11:47:00
【问题描述】:

我的基于 Spring 的 Web 应用程序部署到具有粘性会话的 Tomcat 集群(4 个以上节点)中的生产环境。几年后最大节点数不会超过8-10个。

我需要缓存一些数据(主要是配置),以避免碰到 Oracle。由于这些数据的性质主要是配置,我会说读取与写入的比率是 999999 / 1。

我不想使用完整的缓存解决方案,例如 Infinispan/Hazelcast/Redis,因为它增加了产品的操作复杂性,并且要求缓存一些小的、主要是只读的数据(比如说一些最多百千字节)

起初,我想自己实现一个简单的复制地图,然后我看到[JGroups][1] 附带了[ReplicatedHashMap][1]。我认为它适合我的需要,但我不确定我是否遗漏了什么。

我还应该考虑什么? 有人在生产中使用过吗?

【问题讨论】:

    标签: java caching cluster-computing jgroups


    【解决方案1】:

    ReplicatedHashMap 是 700 行的一类,所以它不是特别复杂,并且使用 JGroups,它已经在生产中使用了十年。

    如果您需要一些简单的东西,没有事务/溢出存储等,那么它可能适合您的工作。请注意,您可以使用 RHM 作为模板对其进行修改和/或编写自己的。

    RHM 将所有数据复制到所有节点,因此如果您有很多节点(您没有),或者您的数据很大,那么 ReplCache 可能是更好的选择。

    【讨论】:

    • 感谢贝拉班的意见。我想存储在缓存中的一件事是加密密钥,现在我看到ReplicatedHashMap 正在使用 UDP 协议来同步节点,如果其中一个节点未能接收到旋转密钥会发生什么?使用过时的加密密钥加密数据是一个禁忌,所以也许我的要求毕竟需要交易。我可以继续在 JGroups 中使用 UDP 进行发现和 TCP 同步吗?
    • 请注意,RHM 可以使用 any 配置,无论是 UDP 还是 TCP。一个节点最终将(通过重传)接收所有消息,除非它崩溃。
    猜你喜欢
    • 1970-01-01
    • 2017-11-09
    • 1970-01-01
    • 2013-02-22
    • 2018-05-25
    • 1970-01-01
    • 1970-01-01
    • 2023-03-12
    • 1970-01-01
    相关资源
    最近更新 更多