Redis 缓存 vs 直接使用内存
Posted
技术标签:
【中文标题】Redis 缓存 vs 直接使用内存【英文标题】:Redis cache vs using memory directly 【发布时间】:2013-10-28 23:01:35 【问题描述】:我还没用过Redis,但听说过,打算试试缓存存储。
听说 Redis 使用内存作为缓存存储数据库,那么如果我使用变量作为对象或字典数据类型来存储数据有什么区别呢?喜欢:
var cache =
key:
,
key:
...
Redis 有什么优势?
【问题讨论】:
【参考方案1】:Redis 是一个远程 数据结构服务器。它肯定比仅将数据存储在本地内存中要慢(因为它涉及套接字往返来获取/存储数据)。不过,它也带来了一些有趣的特性:
应用程序的所有进程都可以访问 Redis,可能运行在多个节点上(这是本地内存无法实现的)。
Redis 内存存储非常高效,并且在单独的进程中完成。如果应用程序运行在内存被垃圾回收的平台(node.js、java 等)上,它允许处理更大的内存缓存/存储。在实践中,非常大的堆在垃圾回收语言中表现不佳。
如果需要,Redis 可以将数据持久化到磁盘上。
Redis 不仅仅是一个简单的缓存:它提供了各种数据结构、各种项目驱逐策略、阻塞队列、发布/订阅、原子性、Lua 脚本等......
Redis 可以使用主/从机制复制其活动,以实现高可用性。
基本上,如果您需要在共享相同数据的多个节点上扩展您的应用程序,那么将需要 Redis(或任何其他远程键/值存储)之类的东西。
【讨论】:
你的最后一点尤其让人觉得像Rlite 这样的东西有点毫无意义——字典存储在大多数只有一个进程的用例中同样适用。对吗? 是的。 IMO 对 Rlite 的兴趣非常有限。 感谢这些提示,所以 Redis 的扩展性很好,但我假设在一个简单的聊天应用程序的情况下,平均有 300 - 500 个对象要在内存中检索,内存数据结构将完成工作非常好,如果不是更快,因为这些数量很少? @DidierSpeziavery large heaps do not perform well with garbage collected languages
你能解释一下原因吗?
@roottraveller,我相信这是因为垃圾收集过程通常必须中断您的应用程序的执行(“stop-the-world”)以释放堆内存,并且堆越大,这种中断通常会持续更长时间。【参考方案2】:
目前我们更倾向于无服务器架构,每个请求可以转到不同的容器。在这种情况下,redis 可以发挥非常重要的作用。
我们不能在 server less 中使用简单缓存,因为我们不能确定我们的请求会在存储简单缓存的同一容器中得到服务。
在这种情况下,我们必须使用 redis,因为它在远程位置存储缓存,我们甚至可以在无服务器架构中访问容器更改。
【讨论】:
以上是关于Redis 缓存 vs 直接使用内存的主要内容,如果未能解决你的问题,请参考以下文章
AWS Elasticache - Redis VS MemcacheD