performance - 平衡 Redis 查询和进程内内存？

Question

我是一名软件开发人员，但想成为服务器可扩展性领域的新架构师。

在多个服务使用同一数据集的情况下，旨在扩展冗余和负载平衡。

问题是:在一个理想主义的系统中，服务是否应该尝试优化它们的内部处理以减少对远程服务器缓存的查询量，从而以牺牲一些本地内存和代码库为代价来获得更好的性能和更少的带宽，或者是每次任何事务需要对数据进行处理时，最好都将远程缓存作为单个事务点进行查询吗？

当我在网上阅读有关 Redis 甚至一般数据库用法的信息时，后者似乎是常见的选择。扩展应用程序的每个节点都没有内存，并且在每个事务中直接读取和写入远程缓存。

但是作为开发者，请问这不是极大的资源浪费吗？无论您是在电子芯片级别、线程间、进程间还是机器间进行设计，我都相信每个子系统都有责任尽其所能优化其处理而不依赖于外部世界，如果它可以因此减少整体操作时间。

我的意思是，如果相同的数据从同一服务读取数百次或多次而没有更改(写入)，那么保留本地缓存并等待更改通知(发布/订阅)和只读取这些更改来更新缓存，而不是在每次事务需要时读取更大的数据部分？另一方面，我知道这种方法意味着相同的数据将在多个地方复制(更多的 ram 使用)并且需要某种过期系统来防止缓存填满。

我知道 Redis 的构建速度很快。但无论它有多快，在我看来，直接从本地内存读取与查询外部服务、通过网络传输数据、分配内存、反序列化为适当的对象并在完成后进行垃圾回收之间仍然存在巨大差异。任何人都有进程内字典查询与本地主机上的 Redis 查询之间的基准数字？在更大的计划中，它是微不足道的时间还是一个重要因素？

现在，我认为到目前为止我的问题的真正答案是“这取决于您的使用场景”，所以让我们详细说明一下:

我们的一些服务会在数据发生变化的情况下触发操作，其他服务会定期处理数据，其他服务会定期从外部网络源读取新数据，最后其他服务负责向用户呈现数据并让他们触发某些操作并引入新数据.因此，它比需要服务的单个网页要复杂一些。我们在大多数服务中已经有了一个缓存系统代码库，并且我们有一个消息代理系统来通知数据更改和触发操作。目前每种类型只存在一项服务(未扩展)。它们通过消息传输较小的 volatile 数据，并通过 SQL 传输更大更持久(更改频率较低)的数据。我们正在将几乎所有数据移动到 Redis 以简化可扩展性和性能。现在有同事在讨论到底是完全放弃缓存系统，用Redis作为通用的全局缓存，还是保留我们的通知/刷新系统。我们想知道外部世界对此有何看法。谢谢

(该死的，这么多文字)

Answer 1

我倾向于尽可能多地使用进程内内存。任何远程查询都会引入延迟。您可以使用混合方法并利用进程内缓存来提高速度(而且速度要快得多)，但在其上放置一个明显更短的 TTL，然后一旦过期，进一步返回到 Redis。