Performance 平衡Redis查询和进程内存？

我是一名软件开发人员，但希望成为服务器可伸缩性领域的新架构师

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

问题是：在理想主义体系中，服务是否应该尝试优化其内部处理，以减少对远程服务器缓存的查询量，从而获得更好的性能和更少的带宽，而代价是一些本地内存和代码库，还是在每次需要处理任何事务时都将远程缓存作为单个事务点进行查询对数据做了什么

当我在线阅读有关Redis甚至一般数据库使用的文章时，后者似乎是常见的选择。缩放应用程序的每个节点都没有内存，在每个事务上都直接读写到远程缓存

但是作为一个开发人员，我问这是否是一个巨大的资源浪费？无论您是在电子芯片级、线程间、进程间还是机器间进行设计，我确信每个子系统都有责任尽其所能优化其处理过程，而不依赖外部世界（如果可能的话），从而缩短总体操作时间

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

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

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

我们的一些服务会在数据更改的情况下触发操作，其他服务会定期处理数据，其他服务会定期从外部网络源读取新数据，最后其他服务会负责向用户提供数据，让用户触发一些操作并引入新数据。所以它比一个值得服务的网页要复杂一些。在大多数服务中，我们已经有了一个缓存系统代码库，并且我们有一个消息代理系统来通知数据更改和触发操作。目前每种类型仅存在一个服务（未缩放）。它们通过消息传输小的易失性数据，通过SQL传输大的更持久（更改频率更低）的数据。我们正在将几乎所有数据移动到Redis，以简化可扩展性和性能。现在，一些同事正在热烈讨论我们是否应该完全放弃缓存系统，使用Redis作为通用的全局缓存，还是保留我们的通知/刷新系统。我们想知道外部世界是怎么想的。谢谢

---

（该死的，那是很多文本）

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