Web services 使用RabbitMQ使本地内存缓存失效的陷阱

我有一个JavaWeb服务器，目前正在使用Guava库来处理我大量使用的内存缓存。我现在需要扩展到多个服务器（2+）以实现故障切换和负载平衡。在这个过程中，我从进程内缓存切换到Memcache（外部服务）。但是，我对结果没有太大的印象，因为现在几乎每次调用都必须对另一台服务器进行外部调用，这要比内存缓存慢得多

我在想，不必从Memcache获取数据，我可以继续在每台服务器上使用本地缓存，并在需要更新缓存时使用RabbitMQ通知其他服务器。因此，如果一台服务器对底层数据进行更改，它还将向所有其他服务器广播一条消息，告知它们的缓存现在无效。每个服务器都在广播和侦听缓存失效消息

---

有人知道这种方法的潜在缺陷吗？我有点紧张，因为我找不到其他人在生产中这样做。我看到的唯一问题是，每个服务器都需要更多的内存（内存缓存中），任何给定的服务器都可能需要更长的时间才能获得更新的数据。还有什么吗？

我们对只读数据使用类似的方法，不需要每次更新。我怀疑这对你来说是个好计划。想象一下，每个实例上都应该有一个额外的服务，它将监视队列，并处理对内存中存储的更改。这很难测试

---

您确定大部分时间都花在服务器之间的通信上吗？也许你打了多个电话

我对你的问题有点困惑，所以我想用一种对我有意义的方式重申一下，然后回答我对你问题的看法。如果我与你的想法不一致，请随时发表评论

您有一个web应用程序，它对数据使用进程本地内存缓存。您希望扩展到多个节点，并为您的程序保留相同的结构，而不是依赖具有内置缓存复制的第三方工具（memcached、Couchbase、Redis）。因此，您正在考虑使用RabbitMQ将更改发布到各个节点，以便它们可以相应地更新本地缓存

我最初的反应是，您想要做的最好是使用上述工具之一。除了显而易见的开发和严格的测试之外，Couchbase、Memcached和Redis都是为解决您的问题而设计的

此外，从理论上讲，在水平扩展时，应用程序节点中的可用内存会耗尽，然后会变得一团糟。一旦你达到了这个限制使你的应用程序不可行的地步，你无论如何都会使用其中一个工具，在这一点上，你设计定制解决方案的所有努力都将付之东流

我能想到的唯一例外是，如果你的应用程序是高度计算密集型的，并且没有使用太多内存。在这种情况下，我认为基于RabbitMQ的解决方案很简单，但是如果RMQ中丢失消息，您需要有某种程序来同步服务器之间的缓存。您还需要一种处理节点启动和关闭的方法

编辑

---

考虑到您在评论中所说的访问时间为数百毫秒，我建议您首先检查您的设置。从Memcached（或Couchbase或Redis等）实例读取缓存中单个项目的典型时间为亚毫秒（如果我没记错的话，大约为0.1毫秒），因此缓存服务器的“问题子对象”的性能与应该达到的水平相差几个数量级。从这里开始，然后看看你是否还有同样的问题。

有道理，但这不完全是我的问题。我的原始缓存是进程的本地缓存（将Guava缓存想象成地图或字典）。它没有任何内置机制来扩展到多个节点。Memcache确实有这个功能，这就是我切换到它的原因，但现在缓存不是我的web服务器本地的，它在另一台机器上，这会减慢速度。有什么原因不能在web服务器上运行memcached吗？一些memcached客户端保持与服务器的连接打开，以优化响应时间；我正在努力解决您的用例，即十分之几毫秒就足以导致性能明显下降。你能详细说明一下吗？@ChrisJohnson我很喜欢你的建议，在同一台服务器上运行memcached，我会试试。@rmayer06每次调用memcache大约需要150到200毫秒（几乎所有的时间都花在网络请求上）。由于我现在只将模型存储在缓存中，一些请求需要2个调用（序列化），因为我需要第一个模型来确定第二个调用的模型。我在DZone上发现这一点很有用，但它没有解决其他系统保持缓存一致的消息传递问题。请详细说明您的设置。如果看到响应时间为250-350毫秒，则缓存/服务器配置存在问题。