Memchached 还是 Redis?
该用哪一个? 当我们讨论改进性能的时候, 这是每次技术讨论中最常见的一个问题. 每当性能需要改善时, 采用缓存常常是迈出的第一步. 与此同时, 选择 Memcached 或者 Redis 通常是第一个需要考虑的地方. 哪个能给我们提供更佳的性能? 它们的优点和缺点又是什么?
在设计任何缓存系统时, 我们考虑如下几点:
读 / 写速度
内存使用情况
磁盘 I/O 转储.
伸缩性.
我写这篇教程是考虑到你已经知道了这些缓存的基础知识.
Redis & Memchached 之间的相似之处:
Memcached/Redis 两者都提供基于内存的, 键 - 值数据存储, 尽管 Redis 更准确的说是结构化数据存储. Redis 是内存中的结构化数据存储器, 用于数据库, 缓存, 消息代理. 两者 (Memcached/Redis) 都属于数据管理方案中的 NoSQL 家族, 都是基于键 - 值存储的. 它们都在内存中保存数据, 当然使它们作为缓存层特别有用.
截至今日, Memcached 提供的每项主要功能及其优势, 都是 Redis 功能和特性的子集. 任何用例中可能使用 Memcached 的地方都可以对等的使用 Redis. 它们都是闪电般快速的高速缓存. Memcached 提供的只是 Redis 拥有功能的冰山一角. Memcached 是一个基于易失性内存的键 - 值存储器. Redis 一样可以做到(跟 Memcached 做得一样好), 但是它还是一个结构化数据服务器.
为什么选 Memcached?
当缓存相对较小和使用静态的数据时候, 比如 html 代码片段, Memcached 可能更为可取. Memcached 内部的内存管理在最简单的用例中更为有效, 因为它的元数据消耗相对更少的内存资源.
当数据尺寸是动态的时候, Memcached 的内存管理效率下降的很快, 此时 Memcached 的内存会变成碎片. 而且, 大的数据集经常牵扯到数据序列化, 总是需要更多的空间来存储. 如果你使用 Memcached, 数据会随着重启动而丢失, 重建缓存是个代价高昂的过程.
Memcached 比 Redis 更具优势的另一个场景在伸缩性. 因为 Memcached 是多线程的, 所以你可以通过给它更多计算资源让它轻松扩展. Redis 是单线程的, 可以通过集群无损水平扩展. 集群是一个有效的扩展方案, 但是相对来说配置, 操作复杂. Memcached 不支持复制功能(数据从一台机器自动复制到另外一台).
Memcached 非常适合处理高流量的网站. 它可以一次性读取大量的信息, 并在优秀的反应时间内返回. Redis 不但能处理高流量的读, 还能处理繁重的写入.
为什么选 Redis?
Redis 有五种主要的数据结构可以选择. 通过对缓存数据智能化的缓存和处理, 它为应用程序开发人员打开了存在各种可能的新世界. 由于其数据结构 (使用多种格式存储数据: 列表, 数组, 集合, 有序集合) 特性, Redis 作为缓存系统提供了更多的能力和总体上更好的效率. 缓存使用一种称为 "数据回收" 的机制, 通过从内存中删除旧数据为新数据腾出空间. Memcached 的数据回收机制使用了 LRU(Least Recently Used - 最近最少使用)算法, 但回收与新数据近似大小的数据时有点随意性.
Redis 允许对回收进行细粒度的控制, 让你选择六种不同的回收策略. Redis 同时支持惰性 (被动) 和主动回收, 只有在需要更多空间或主动激活时才回收数据. 另一方面, Memcached 只支持惰性回收.
以下是 redis 提供的一些功能, 可以用于 "真实" 数据存储, 而不仅仅是缓存.
强大的数据类型和可利用它们的强大命令支持. 哈希, 有序集合, 列表等.
默认的磁盘持久化支持
使用乐观锁的事务支持 (WATCH/MULTI/EXEC)
发布 / 订阅功能, 速度极快
高达 512MB 的键值尺寸上限(Memcached 每个键值限于 1MB 大小)
Lua 脚本支持 (2.6 及以上版本)
内置集群支持 (3.0 及以上版本)
一切都极快
强大的数据类型尤为重要. 它们允许 Redis 提供一个出色的共享队列 (list), 一个很棒的消息传递解决方案(pub/sub), 一个存储会话信息(hashes) 的好地方, 还有一个引人注目的高分值追踪区域(sorted sets). 它们仅仅是简单探讨就能得到的使用样例.
结论
Redis 与 Memcached 相比, 性能和内存使用情况相当相似. 除非你已经在 Memcached 上投入了大笔资金, 否则向前推进使用 Redis 是显而易见的解决方案. 不仅 Redis 是更好的选择, 它还支持全新类型的用例和使用模式.
Redis 可能会非常有用的一些示例应用程序:
电子商务应用: 大多数的电子商务应用量级比较重, Redis 可以提升你的页面加载速度. 你可以存储所有的配置文件到 Redis, 从内存中读取这些配置信息速度会非常快速. 你也可以在 Redis 中存储完整的页面缓存, 因为它的键值容量很大. 你也可以存储会话信息到 Redis.
物联网应用: 在物联网应用中, 物联网设备非常频繁的发送数据到服务器, 比如每秒钟数千条. 在把它们存储到任何持久性存储器之前, 你可以先把这些高容量的原始数据推送到 Redis.
实时分析: 可以在 Memcached 上实现一个实时的分析引擎, 以数据库为后盾. 但是 Redis 非常擅长统计列表和一系列事物. 在所有的 Redis 功能特性中, 它对键值进行排序的能力超过了 Memcached, 还有计算一组页面的点击次数等数据, 然后将这些数字汇总进入分析系统. 这些数据可通过工作人员输入到更大的分析引擎, 在这些应用场合选择 Redis 是正确的决定之一.
最后一件事: 不管你选择什么, 缓存系统都不是数据库. 你不能光靠缓存, 系统同时需要缓存和数据库.
这段是我的评论. 总体上看, Redis 功能特性远优于 Memcached, 完全是下一代产品. 选择哪个使用似乎答案很明确. 但是必须指出, Redis 的单线程设计, 同时也带来了一些重要的隐患. Redis 有数据持久化功能, 这个功能与 Redis 的单线程特性结合, 就成了 Redis 故障的高发区域. 默认的 RDB 持久化会阻塞线程, 使得 Redis 对正常请求无法响应, 在高流量网站上容易出现大量请求错误. 这在系统中称为 "涌现", 当然这是坏的一个. 当然后来 Redis 也发展出了 AOF 持久化方式(默认没有打开, 要手工开启), 一定程度上减缓了 Redis 的持久化问题. Redis 会 fork 一个子进程来单独处理持久化. 可是 fork 功能并非无代价, 它一样有消耗内存资源, 影响主程序响应请求的问题. 阻塞是 Redis 应用的噩梦, 跟 Node.js 一样. 所以出现故障的时候, 可以多在这个角度上分析原因, 也许能很快的解决.
来源: http://stor.51cto.com/art/201807/578015.htm