问是否有可能将对象保存在内存中，以便比Redis或Memcached更快地存储缓存？

EN

如果只有一台机器和一个进程，那么您可以将对象图存储在本地内存中，这是正确的。如果有多个进程，那么它必须位于共享内存中，这就打开了一整罐蠕虫，这些蠕虫可能被第三方产品(如Redis/memcached )解决，也可能无法解决。例如，现在必须管理并发性(例如，确保一个进程在试图读取图形的同时，另一个进程正在修改该图，或者一个更雄心勃勃的无锁算法)。事实上，这也必须在单个多线程进程中解决。

对象引用，在共享内存的情况下，如果它们是内存指针，只要共享内存段映射到每个进程中的相同地址，它们仍然可以使用。根据共享内存段的大小、进程的大小以及每个进程的内存映射，这可能是可能的，也可能是不可能的。使用系统生成的对象标识符/引用(例如，连续递增的4字节或8字节整数)可以避免这个问题。

最后，如果将对象图存储在任何存储库中，则必须将其序列化/反序列化为/退出存储库。

您提到的缓存被设计为具有大量特性和选项的分布式缓存。将对象或特别是对象树保存在一个(全局)变量中，以便在一个进程中使用，总是比从另一台计算机加载对象树的反序列化工作要快得多，等等。

但这不是Redis & Co的用例，只要您尝试用命名管道(或任何其他技术)实现自己的分布式缓存，您就会发现Redis有其存在的权利。

换句话说:一旦您将对象移动到机器边界上，您就必须序列化和反序列化它们。您可能不知道底层传输协议是否为您做到了这一点。

将对象保持在内存中有一些优点和缺点。让我们看看他们

优点：

• 将不需要序列化和反序列化成本。
• 执行分析(节省序列化成本)将更容易。
  • 在MapReduce中执行分布式缓存函数时，对象不以二进制形式存储，以减少分析成本。

​

缺点

• 序列化实际上通过删除.NET元数据开销(RAM是宝贵的)来减少数据大小。
• 可以预测缓存的大小。
• 需要时执行加密或压缩。
• 通过网络传送
• 实现自定义序列化器以选择要存储的内容
• 二进制数据没有语言障碍(如果您有自己的序列化程序)

这些只是我认为是正确的一些利弊。我相信还会有更多

了解这些优点和缺点，大多数或所有分布式缓存选择序列化，即使缓存保持在进程中。当我们考虑大部分用例时，序列化成本也不是那么高。

此外，@Waescher的观点也是正确的，当涉及到网络时，所有类型的数据都必须转换为字节进行传输。