最近和面试官聊天偶尔意识到，自己虽然曾经根据公司架构师的规划给开发同学搭建过Redis集群，也在自己的项目里用到过Redis做消息队列，但相比于同样是缓存的Memcache，Redis到底好在哪里，并不是十分清晰，虽然我们作为维护人员在对缓存使用的上会没有开发同学那么的深入，但在进行服务选型时还是需要参考其使用情况提出建议，于是整理学习下。

  另外，这里有两个名词需要区分下：Memcache是我们这里提到的内存对象缓存系统，Memcached是该系统的主程序文件（守护进程）。

  Redis和Memcache二者都是在内存中缓存数据从而减少对数据库的读取，而且性能相近。 Redis单进程单线程避免了线程切换和竞态产生的消耗（Redis官方的性能解释），因此不比采用单进程多线程的Memcached慢。

  所以，其实Redis不一定就优于Memcached，还是得看使用场景和需求。

  但从实际部署和个人自用两个方面的体验效果来讲，还是推荐优先上新兴的Redis。

常见的需要优先考虑Redis的原因：

• 数据结构丰富

  Redis不仅支持简单的key-value类型的数据结构，同时还提供了list，set，zset，hash等丰富的数据结构，在一定程度上带来了操作的便利性。其中，自己在缓存运维脚本持续输出的字符串时，使用的就是现成的list类型来实现消息队列。而Memcache只支持key-value数据结构，想实现队列就需要自己加额外的控制代码。

• 分布式实现方式

  Memcache需要在客户端实现分布式（也可以使用代理）， 而Redis有现成的集群解决方案Redis Cluster，在服务端就可以实现，灵活性会高很多，便于扩展的同时可以添加slave实现备份。

• 数据持久化

  Redis支持数据持久化写入磁盘，在一定程度上增强了数据的可靠性，便于数据恢复。当然，作为纯粹的读缓存辅助MySQL使用时，Redis不应开启持久化，否则需要考虑两边数据冲突的问题。

特定情况下使用Memcache的考虑：

• 业务单纯

  当业务只涉及很细碎的静态数据，不需要复杂的数据类型，此时Memcache的额外开销相比就很小，性能会更好。

• 多核环境

  Redis出于最初的单进程单线程设计初衷，更喜欢大缓存+快速CPU的环境，而不是多核CPU的环境，所以此时可以考虑下Memcache利用机器性能。

选型时其他需要考虑的因素

• 数据大小衡量

  Memcache单个key-value大小有限，一个value最大只支持1MB，而Redis的key最大支持512MB。

• 安全衡量

  Memcache本身不带安全认证功能，只能通过外部措施增加安全性，而Redis可以直接开启密码认证提高安全性。