Redis 和 Mecached 到底哪个好?

Posted by 陈树义 on 2018-05-28

文章首发于微信公众号「陈树义」,专注于 Java 技术分享的社区。点击链接扫描二维码,与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

说起缓存框架,我们最常用的缓存框架有 memcached、Redis 这两个,但它们之间其实是有差异的。

Memcached 的诞生

2003年5月,Brad Fitzpatrick 发布了第一个版本的 Memcached,一开始主要是为了解决 LiveJournal 网站访问缓存问题而诞生的,这个版本的 Memcached 使用 Perl 语言编写。之后 Anatoly Vorobey 使用 C 重写了 Memcached。现在 Memcached 已经被广泛应用于 YouTube、Reddit、Facebook 等网站。

说起 Memcached 的诞生,主要还是因为关系型数据库在存储性能上的瓶颈。因为进入21世纪,随着个人电脑的普及,世界网民数量急剧攀升,网站的访问量也随之攀升。

因为关系型数据库需要将数据持久化,所以会有一些写硬盘IO的过程,因此在写入数据上会有瓶颈。而为了解决硬盘IO速度慢的问题,Memcached 则是将所有数据存储在了内存中,从而能实现快速的数据写入和读取。

也是因为 Memcached 将数据存储在内存中,没有实现持久化,所以当出现一些意外情况,例如:断电重启、机器宕机等情况,Memcached 存储的数据会全部丢失,我们只能重新从数据库中读取一次,再加载到 Memcached 中。

除此之外,Memcached只支持单一的 key-value 存储,所以这里面存储的数据类型单一,无法适应多样化的业务发展。

Redis 的诞生

正是因为以上问题的存储,所以在2009年5月的时候Redis诞生了。Redis创建者看到了Memcached身上存在的许多问题,所以创建了Redis缓存框架。

在Redis缓存框架中,它支持多达 6 种类型的数据存储,并且提供了多个原子命令操作。并且Redis还支持了将数据持久化到本地文件,这样当发生意外时就不需要再从数据库读取一遍数据了,直接读取本地文件恢复即可。

文章首发于微信公众号「陈树义」,专注于 Java 技术分享的社区。点击链接扫描二维码,与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

到底哪一个好?

从两个缓存框架的发展历程来看,我们可以知道Redis是Memcached的升级版本,Memcached具有的功能Redis基本上都具备了。

所以很多时候我们都是使用Redis作为首选的缓存框架,当然了Memcached也有一些比Redis好一些的性能,比如在存储完全静态的小量 key-value 数据时,Memcached会比Redis快一些。

但只要数据量稍微大一点,或者数据是动态的,那么Memcached的性能就会直线下降。

所以即使Memcached在某些方面有细微的优势,但总体上Redis还是优于Memcached这个缓存框架的。

一些思考

文章首发于微信公众号「陈树义」,专注于 Java 技术分享的社区。点击链接扫描二维码,与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

最近在思考数据库以及缓存的问题,发现这些知识点其实是有一点关联的,于是这篇文章通过一个连环提问的方式将这些知识点串联起来。

  • 问:为什么要用 Memcached、Redis,直接用 MySQL 这些数据库不好吗?

答:因为 MySQL 等关系型数据库无法承受巨大的数据库访问量。

  • 问:为什么 MySQL 数据库无法承受巨大的访问量,而 Redis Memcached 却可以?

因为 MySQL 使用文件去存储数据,这就意味着它的查询和写入速度受限于硬盘的速度。虽然 MySQL 也使用了内存缓存一部分数据,但这只能减少一部分的查询请求,如果查询请求数变多,同样会到达硬盘的 IO 瓶颈。

另一方面,关系型数据库为了实现数据的强一致性,在每次写入数据的时候会对相关的数据进行加锁操作,这样就导致在某个时刻,相关的数据只能有一个线程在操作,这样也从某种程度上限制了 MySQL 的读写性能。

如果此时查询缓存并没有相关数据,那么还会有一部分 IO 等待的事件,从而导致加锁时间变长。

而 Redis、Memcached 之所以能够承受得住 MySQL 无法承受的海量查询,很大程度上是因为他们将所有数据都存在了内存中,所以它们并不需要进行 IO 等待,直接可以从内存中查询数据并返回。

而内存的读取效率则是硬盘的 40 倍左右,存储介质的巨大区别导致了他们的应用特性。

  • 问:那有了 Memcached 不就好了吗,为什么还要用 Redis 呢?

答:这就要说到这两种缓存的发展历史了。一开始是 2003 年发布的,一开始是为了解决数据库的读写瓶颈问题,于是将一些热点数据存储在内存中,从而有了 Memcached。

但经过几年的使用,人们发现 Memcached 存在一些问题,例如 Memcached 只支持 Key - Value 的字符串数据存储,Memcached 无法持久化数据,一旦重启服务器数据便丢失了。

出于这些原因,2009 年一些工程师在 Memcached 的基础之上打造了 Redis 框架,它与 Memcached 相比,支持更多的数据类型存储,例如:String, List, Set, SortedSet, Hash 等。此外还支持将存储在内存中的数据持久化到文件中,从而实现数据持久化。

另外 Redis 支持更大的数据存储,key-value 的存储大小可达 512M,而 Memcached 的 key 大小只有 512KB,而 value 则只有 1 M 大小。

另外它还支持许多的原子操作。因为 Redis 与 Memcached 相比有上述的优点,所以现在越来越多的人开始使用 Redis 作为缓存框架。

  • 问:但按我所知,现在还是有许多公司使用 Memcached 作为缓存框架。换句话说,你觉得什么时候应该使用 Memcached,什么时候应该使用 Redis?

答:首先,无论 Redis 还是 Memcached,它们都是一个 NoSQL 数据库,并且都将所有数据存在内存中。现在确实有些公司还是使用 Memcached 框架作为缓存,Memcached 在某些方面确实比 Redis 好一些,虽然这些优势非常小。

文章首发于微信公众号「陈树义」,专注于 Java 技术分享的社区。点击链接扫描二维码,与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

例如 Memcached 在处理小数据量静态数据的速度会非常快,但是一旦数据量变大或者数据变动频繁,那 Memcached 的处理速度就会急剧下降。

另外一个 Memcached 的优势是 Memcached 是多线程的,所以如果你想提高 Memcached的性能,你可以直接给它换一个性能更加强劲的 CPU 就可以。

但是对于 Redis 而言,因为 Redis 是单线程的,所以如果你想提升 Redis 的处理能力,那么你只能多部署一台 Redis 服务器,这比起 Memcached 来说比较麻烦。

总结来说,Memcached 比起 Redis 来说,只有小数据量存储以及横向拓展这两个方面能勉强说得上「优势」,但其实 Redis 也能做得同样好,甚至超过它,只不过是需要花多点学习成本而已。

所以,如果你之前已经非常了解 Memcached 了,花了很多时间学习 Memcached 的知识,那么你可以选择 Memcached。

否则选择 Redis 是一个更好的选择,因为所有 Memcached 能做的,Redis 也能做,而且 Redis 能做到更多 Memcached 无法做到的事情。

  • 问:那 Redis 除了作为缓存之外,还有其他什么作用吗?

答:作为缓存可能是 Redis 最广为人知的作用吧,但 Redis 除了作为缓存,还能作为消息队列解决方案、分布式锁等。

  • 问:那 MongoDb 与 Redis 相比有什么优势可言,它更适用于什么场景呢?

答:MongoDb 的出现与 Redis 的出现类似,都是用来解决 MySQL 无法实现海量访问而存在的。但 Redis 仅仅是一个 key-value 的缓存系统,其几乎没有任何数据库特性,在那些许多进行查询的场景中,redis 无法胜任。

在这个时候 MongoDb 凭借其出色和丰富的查询功能脱颖而出。

另外 MongoDb 也能存储比 MySQL 更加大量的数据。MongoDb 适合那种数据结构经常变化,数据之间没有联系,这种场景适合用 MongoDb,例如多重嵌套的留言回复。

文章首发于微信公众号「陈树义」,专注于 Java 技术分享的社区。点击链接扫描二维码,与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg