在不同主机上具有重复缓存条目的分布式缓存

时间:2016-05-23 10:48:39

标签: java caching memcached distributed-caching

假设我有一个memcache服务器阵列,memcache客户端将确保缓存条目仅在单个memcache服务器上,并且所有客户端将始终向该服务器请求缓存条目......对吗?

现在考虑两种情况:
[1] web-server正在获取大量不同的请求(不同的URL),然后缓存条目将分布在memcache服务器中,请求将扇出到memcache集群。
在这种情况下,将单个缓存条目保留在单个服务器上的memcache策略可以正常工作。

[2]网络服务器正在获得相同资源的大量请求,然后来自网络服务器的所有请求将落在一个不需要的单个内存缓存服务器上。

我要找的是分布式缓存,其中包括:
[1]每个Web服务器都可以指定用于缓存内容的缓存节点 [2]如果任何Web服务器使高速缓存无效,则高速缓存服务器应使其从所有高速缓存节点无效 memcache可以实现此用例吗?

PS:我没有大量的资源来缓存,但我拥有少量的资源,有大量的流量要求同时使用一个资源。

1 个答案:

答案 0 :(得分:1)

Memcache是​​一个很棒的分布式缓存。要了解存储值的位置,最好将memcache集群视为散列映射,每个memcached进程恰好是散列映射中的一个标记孔(当然每个memcached也是一个'内部'散列映射,但这不是对于这一点很重要)。例如,内存缓存客户端使用此伪代码确定内存缓存节点:

index = hash(key) mod len(servers)
value = servers[index].get(key)

这是客户端始终可以找到正确服务器的方式。它还强调了散列函数的重要性,以及如何生成密钥 - 错误的散列函数可能无法在不同的服务器上统一分发密钥....但是,默认的哈希函数在几乎任何实际情况下都应该可以正常工作。

现在你提出问题[2]资源请求是非随机的,特别是有利于一个或几个服务器的情况。如果是这种情况,那么各个节点可能会获得更多请求,但这是相对的。根据我的经验,memcache每秒能够处理大量更多的请求,而不是Web服务器。 It easily handles 100's of thousands of requests per second on old hardware。因此,除非你的内存服务器比memcache服务器多10-100倍,否则你不太可能遇到问题。即使这样,您也可以通过升级单个节点来获得更多CPU或更强大的CPU来解决问题。

但是让我们假设最糟糕的情况 - 您仍然可以通过以下方式实现此目的:

  • 将每个内存缓存安装为单个服务器(即不是分布式缓存)
  • 在您的Web服务器中,您现在负责管理与每个服务器的连接
  • 您还负责确定哪个 memcached进程将每个键/值传递给,实现目标1
  • 如果Web服务器检测到缓存失效,它应该遍历服务器,使每个缓存失效,从而实现目标2

我个人对此有所保留 - 按照规范,您将禁用缓存的分布式方面,并且分发是服务的关键功能和优势。此外,您的应用程序代码将开始需要了解各个缓存服务器,以便能够以不同的方式处理每个缓存服务器,这在架构上是不合需要的,并引入了大量新的配置点。

任何分布式缓存的想法是从客户端删除位置(*)的所有权。因此,分布式缓存和DB不允许客户端指定写入数据的服务器。

总之,除非您的系统每秒预计100,000k或更多请求,否则您在实践中会遇到这个特定问题是值得怀疑的。如果这样做,请缩放硬件。如果这不起作用,那么您将在memcache上编写自己的分发逻辑,复制,刷新和管理层。如果真的非常必要,我只会这样做。有一个old saying in software development

  

计算机科学中只有两件事:缓存失效   并命名事物。

     

- Phil Karlton

(*)一些分布式缓存重复条目以提高性能和(另外)服务器出现故障时的弹性,因此数据可能同时位于多个服务器上