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

Question

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

请给我建议最好和有效的方法。

Answer 1

而不是尝试同步两个服务器实例之间的缓存数据，为什么不使用memcached/couchbase或redis之类的东西集中缓存？像ehcache一样使用分布式缓存要复杂得多，而且容易出错，而使用像上面提到的缓存服务器来集中缓存的数据。

作为我原始答案的附录，在决定使用哪种缓存方法（内存，集中式）时，需要考虑的一件事是要缓存的数据的波动性。

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

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

编辑：

一个问题，在约一个集中的缓存（我猜对内存分布式缓存一样的东西）的优点的意见有人问。我会就此提出我的看法，但首先是标准免责声明。集中式缓存不是万能的。它旨在解决与jvm内存缓存相关的特定问题。在评估是否切换到它之前，您应该首先了解您的问题，并确定它们是否符合集中缓存的好处。集中式缓存是一种体系结构变化，它可能会带来问题/警告。不要简单地转换它，因为有人说它比你所做的更好。确保原因适合问题。

好吧，现在我认为集中式缓存可以解决哪些问题可以解决vs-jvm内存（可能分布式）缓存。我要列举两件事，虽然我确信还有更多。我的两个大个子是：整体内存占用量和数据同步问题。

让我们从整体内存占用量开始。假设您正在执行标准实体缓存以保护您的关系数据库免受过度的压力。我们还要说，为了真正保护您的数据库，您需要缓存大量数据;比如在很多GB的范围内。如果你正在进行in-jvm-memory缓存，并且你说有10个应用程序服务器盒，那么你需要为每个需要在jvm中进行缓存的盒子获得额外的内存（$$$）乘以10记忆。另外，您还需要为JVM分配一个较大的堆来容纳缓存的数据。我认为JVM堆应该小而精简，以减轻垃圾收集负担。如果你有一大堆无法收集的旧世代，那么当你的垃圾收集器进入一个完整的GC并且试图从那个臃肿的旧世代空间中收回东西时，你会压迫你的垃圾收集器。你想避免长时间的GC2暂停时间和膨胀你的老将是不会帮助。另外，如果你的内存需求高于某个阈值，并且你正在为你的应用层运行32位机器，那么你将不得不升级到64位机器，这可能是另一个令人望而却步的成本。

现在，如果你决定集中缓存中的数据（使用类似的Redis或者Memcached的），你可以显著减少缓存数据的整体内存占用，因为你可以有它的一对夫妇的盒子，而不是所有的应用层中的应用服务器框。您可能希望使用集群方法（两种技术都支持它）以及至少两台服务器，为您提供高可用性，并避免缓存层出现单点故障（更多情况在一秒钟内）。通过一台机器来支持缓存所需的内存需求，您可以节省一些可观的$$。此外，您现在可以调整应用程序框和缓存框，因为它们具有不同的用途。可以对应用程序框进行调整以获得高吞吐量和低堆，并且可以调整缓存框以适应大内存。而小堆会肯定帮助应用层框的整体吞吐量。

现在是集中缓存的一个快速点。您应该设置您的应用程序，使其在没有缓存的情况下能够存活，以防其在一段时间内完全关闭。在传统的实体缓存中，这意味着当缓存完全不可用时，您只需要为每个请求直接点击数据库。不是真棒，但也不是世界末日。

好吧，现在为数据同步问题。使用分布式in-jvm-memory缓存，您需要保持缓存同步。对一个节点中缓存数据的更改需要复制到其他节点，并同步到其缓存的数据中。这种方法有点可怕，如果由于某种原因（例如网络故障）其中一个节点不同步，那么当请求进入该节点时，用户看到的数据将不准确D B。更糟糕的是，如果他们提出另一个请求并且击中了不同的节点，他们将看到不同的数据，这会让用户感到困惑。通过集中数据，您可以消除此问题。现在，人们可以争辩说，集中式缓存需要对同一缓存数据密钥进行更新的并发控制。如果两个并发更新进入同一个密钥，那么如何确保两个更新不会彼此跺脚？我的想法是不要担心这件事。当更新发生时，将项目从缓存中删除（并直接写入数据库），并在下次读取时重新载入。这样更安全，更简单。如果您不想这样做，那么如果您真的想更新缓存和数据库更新，则可以使用CAS（检查和设置）功能来替代乐观并发控制。因此，总而言之，如果您集中缓存的数据，则可以节省资金并更好地调整应用程序层机器。由于您处理的数据同步问题较少，因此您也可以获得更好的数据准确性。我希望这有帮助。

Answer 2

首先，尽量忘记过早的优化。你真的需要缓存吗？ 99％，你不需要它。在这种情况下，您的解决方案是删除冗余代码。

如果你需要它，试着停止重新发明轮子。有完美的现成的图书馆。例如ehCache具有分布式模式。

Answer 3

使用HazelCast。它允许使用多播协议的服务器之间的数据同步它很容易使用。它支持锁定和其他功能。