Java 在两台服务器之间同步缓存数据的最佳方法

要在两台服务器之间同步缓存数据。这两个数据库共享同一个数据库，但为了更好地执行数据，我在启动时将数据缓存到哈希映射中。 因此，您希望在不重新启动服务器的情况下同步缓存的数据。（两台服务器同时启动）

---

请给我建议一种最佳且高效的方法。

与其尝试在两个服务器实例之间同步缓存数据，不如使用memcached/couchbase或redis之类的工具集中缓存？与使用上述缓存服务器集中缓存数据相比，将分布式缓存与ehcache之类的东西结合使用要复杂得多，而且容易出错

作为我最初答案的补充，在决定使用何种缓存方法（在内存中，集中式）时，需要考虑的一件事是正在缓存的数据的波动性

如果数据存储在数据库中，但在服务器加载数据后没有更改，那么您甚至不需要在服务器之间进行同步。只需让他们各自从源代码将这些静态数据加载到内存中，然后按照自己的快乐方式做任何事情。数据不会改变，因此不需要引入复杂的模式来保持服务器之间的数据同步

如果数据确实存在一定程度的波动性（比如说，您正在缓存从数据库中查找的实体数据，以便将点击保存到数据库中），那么我仍然认为集中式缓存比内存中的分布式和同步缓存更好。您只需要确保对缓存的数据使用适当的过期时间，以允许不时对数据进行自然刷新。此外，您可能希望在特定实体的更新路径中删除集中存储中的缓存数据，然后在下一次请求该数据时让它从缓存中重新加载。这比尝试执行真正的直写缓存要好，在这里，您可以写入底层存储以及缓存。数据库本身可能会对数据进行调整（例如，通过默认不适用的值），在这种情况下，缓存的数据可能与数据库中的数据不匹配

编辑：

评论中提出了一个关于集中式缓存优势的问题（我猜是针对内存中的分布式缓存）。我会提供我的意见，但首先是一个标准的免责声明。集中式缓存不是万灵丹。它旨在解决与jvm内存缓存相关的特定问题。在评估是否切换到它之前，您应该首先了解您的问题是什么，并查看它们是否适合集中缓存的好处。集中式缓存是一种体系结构更改，它可能会有自己的问题/警告。不要因为有人说它比你现在做的更好，就转向简单。确保原因与问题相符

好的，现在我来谈谈集中式缓存可以解决jvm内存（可能还有分布式）缓存中的vs问题。我将列出两件事，尽管我肯定还有一些。我的两大问题是：总体内存占用和数据同步问题

让我们从总体内存占用开始。假设您正在进行标准实体缓存，以保护关系数据库免受过度压力。也就是说，为了真正保护数据库，您需要缓存大量数据；比如说在很多GB的范围内。如果您在jvm内存中进行缓存，并且您说有10个应用程序服务器框，那么您需要为每个需要在jvm内存中进行缓存的框获取额外的内存（$$$）乘以10。此外，为了容纳缓存的数据，还必须为JVM分配一个更大的堆。我的观点是，JVM堆应该很小，并且经过优化，以减轻垃圾收集负担。如果您有大量的旧Gen无法收集，那么当垃圾收集器进入一个完整的GC并试图从臃肿的旧Gen空间中获取一些东西时，您将给它带来压力。你想避免长时间的GC2暂停，而你的老一代人的臃肿也帮不上忙。另外，如果您的内存需求高于某个阈值，并且您的应用层恰好运行32位计算机，则您必须升级到64位计算机，这可能是另一个令人望而却步的成本

现在，如果您决定集中缓存数据（使用Redis或Memcached之类的工具），则可以显著减少缓存数据的总体内存占用，因为您可以将其放在应用层的几个盒子上，而不是所有的应用服务器盒子上。您可能希望使用集群方法（两种技术都支持）和至少两台服务器来提供高可用性，并避免缓存层中出现单点故障（稍后将详细介绍）。通过一台拥有两台机器来支持缓存所需的内存需求，您可以节省大量的$$。此外，您现在可以对应用程序框和缓存框进行不同的调优，因为它们有不同的用途。应用程序盒可以调整为高吞吐量和低堆，缓存盒可以调整为大内存。拥有较小的堆肯定会有助于提高应用层框的总体吞吐量

现在是集中缓存的一个要点。您应该以这样一种方式设置您的应用程序，即它可以在没有缓存的情况下生存，以防它完全停机一段时间。在传统的实体缓存中，这意味着当缓存完全不可用时，每个请求都直接命中数据库。不可怕，但也不是世界末日

好的，现在讨论数据同步问题