Redis是sidecar还是客户端服务器模式



在kubernetes中使用redis作为sidecar的优点和缺点是什么?当在每个应用程序pod中添加redis容器时,是否可以拥有持久性缓存?这会影响缓存的可用性可扩展性

我很难想象将Redis作为sidecar运行有什么好处。我总是将它作为一个单独的部署(如果启用了持久性,则为有状态集(和一个单独服务来运行。

如果Redis在自己的pod中,那么:

  • 如果您的应用程序有多个副本,它们将共享相同的Redis
  • 当您重新部署应用程序时,它不会终止并重新启动Redis
  • 如果为Redis启用了持久性,您就不需要使用持久性存储来配置应用程序pod

考虑到Redis的整体功能(主要是内存存储,有限的数据类型支持(,简单地将这些缓存数据存储在应用程序中的单例对象中或多或少相当于将Redis作为sidecar运行(每个pod一个缓存数据副本,删除pod时数据会丢失(。

我同意David Maze的回答。在这个操作中,REDIS是一个常见的长期缓存。所有pod都进入同一个缓存,因此它们可以重用它,并且它具有一致的输出。

另一方面,我也在评估redis缓存的sidecar模型,简而言之,这完全取决于您对一致性的需求。

这个sidecar redis意味着每个微服务pod都有自己的redis。因此,当每个微服务进入数据库时,它会将对象存储在自己的redis中。每当读取相同的对象时,微服务就会转到redis,而不是数据库。这样可以节省大量的数据库读数,但会影响一致性。它还为我节省了$$的云数据库阅读费用。

在我的情况下,缓存将在1分钟左右到期,因此在我的例子中,两者之间缺乏一致性是可以的。

在可扩展性和可用性的情况下,我甚至会说它可以提高它,因为你可以很容易地运行许多pod。即使在redis pod上设置最大内存,当达到极限(150mb?(时,也可以轻松地重新启动它。

最新更新