百万级运维经验二:Redis和Memcached的选择

标签: 百万 运维 经验 | 发表时间:2014-05-24 08:20 | 作者:reallypride
出处:http://blog.csdn.net

看到很多人推荐使用Redis代替Memcached,我觉得这两个是不一样的东西,它们的关系应该是共存而不是替代。

Memcached是个纯内存型的缓存系统,支持数据类型单一,单个缓存数据有限制,支持分布式,我觉得这是个很理想的缓存系统。

Redis是个简单的NOSQL数据库,支持几种简单的数据类型,支持主从复制,支持持久化,可以看作是个内存型数据库。

由此可见,Memcached是正宗的缓存系统,Redis是个可以做缓存系统的内存型数据库。

由于Redis的数据可以设置过期时间,支持多种数据类型,数据大小无限制,支持持久化等特点,貌似怎么看都稳压Memcached一筹,替代它好像是大势所趋。

事实并非如此。

网站需要缓存的数据可以分为两种,一种是可丢失性的缓存,这种缓存不在乎被丢失,丢失了就再从数据库或其它地方再读回来,如Session,从数据库查询的数据,应用代码的缓存等;另一种是不可丢失性的缓存,就是其它地方没保存有,只有Redis缓存有的数据。

先说下Memcached和Redis的优缺点:

Memcached是纯内存型的缓存,占用内存小,运行稳定,读写数据很快。Redis的数据可以持久化到硬盘,占用内存大,占用硬盘IO高,在写频繁的时候而硬盘性能又不高的时候(目前只有SSD固态硬盘的性能才高,机械硬盘性能都不高),大大占用CPU资源,读写性能会急剧降低,甚至会崩溃,不稳定。

为什么说Memcached可以缓存Session数据?有的人说,Memcached崩溃会造成Session丢失,我觉得这个可能性真的不大。Session是每个页面都需要读,每个新用户都需要写的,而且大部分的Session数据都是可丢失性的数据(一般网站陌生人Session比登录用户Session要多的多),数据量也很小,非常适合保存在Memcached。

Memcached其实是非常稳定的,目前我们网站每天百万PV,没出现过Memcached崩溃的问题。只要服务器不崩溃,不是人为关闭,Memcached几乎没有崩溃的可能。如果服务器经常崩溃的话,我觉得应该考虑换个好点的服务器而不是把Memcached换成Redis。

当然了,Redis也有其适用的场合,我会在下一篇博文中,详细介绍我的网站使用Redis保存哪些不可丢失性数据。

作者:reallypride 发表于2014-5-24 0:20:35 原文链接
阅读:178 评论:0 查看评论

相关 [百万 运维 经验] 推荐:

百万级运维经验二:Redis和Memcached的选择

- - CSDN博客系统运维推荐文章
看到很多人推荐使用Redis代替Memcached,我觉得这两个是不一样的东西,它们的关系应该是共存而不是替代. Memcached是个纯内存型的缓存系统,支持数据类型单一,单个缓存数据有限制,支持分布式,我觉得这是个很理想的缓存系统. Redis是个简单的NOSQL数据库,支持几种简单的数据类型,支持主从复制,支持持久化,可以看作是个内存型数据库.

百万级运维经验五:服务器内核优化集锦

- - CSDN博客系统运维推荐文章
编辑文件 /etc/security/limits.conf ,添加两行参数:. 这两行参数设置linux系统最大可打开文件数. 编辑文件/etc/sysctl.conf,添加以下参数:. 如果服务器装有Redis,这个参数一定要加,不然Redis有很大的可能无法同步数据到磁盘. 把所有带backlog的参数的值调大,如:.

百万级运维经验四:大流量如何保存文章阅读数

- - CSDN博客系统运维推荐文章
网站文章通常都会有个阅读数,最简单的方法就是每访问一次就加一,这看起来很简单,update一下就可以了. 如果网站访问量很大呢,每天有几十万次的访问呢,一秒钟就要update几次服务器,效率就很低了. 而且,数据库update的时候会锁表,还会影响到读操作,看来只能用缓存了. Memcached是会丢失数据的,不合适;Redis是内存型数据库,可以持久化,就用它了.

百万级运维经验四:服务器的选择和部署

- - CSDN博客系统运维推荐文章
对服务器的选择,我曾经盲目过. 流量大了服务器顶不住怎么办,我那时候的想法就是加配置,4核变8核,8核变16核,内存也加,4GB变8GB变16GB,为什么不加服务器呢,麻烦嘛,觉得提高服务器配置的效果也是一样的. 后来我才明白,这种想法是错误的,还是停留在个人电脑的思维. 我发现,增加了服务器配置并不能给我带来相应的性能提升,我对服务器和操作系统没有特别深的了解,我个人觉得原因如下:.

ZooKeeper运维经验

- - Juven Xu
ZooKeeper 是分布式环境下非常重要的一个中间件,可以完成动态配置推送、分布式 Leader 选举、分布式锁等功能. 在运维 AliExpress ZooKeeper 服务的一年多来,积累如下经验:. 3台起,如果是虚拟机,必须分散在不同的宿主机上,以实现容灾的目的. 如果长远来看(如2-3年)需求会持续增长,可以直接部署5台.

百万级运维经验一:Mongodb和Redis数据不能放在同一个服务器

- - CSDN博客系统运维推荐文章
一开始时,为了省服务器,把Mongodb和Redis放在一个服务器上. 网站每到高峰期都特别卡,还经常出现502. 找了很久的原因,发现硬盘的写数据很大,IOPS也很高,排查了很多原因都没找到. 然后再仔细研究监控,发现写硬盘的操作很有规律,每隔几分钟就有一次频繁的写硬盘,联想到Redis同步数据到硬盘的间隔就是几分钟,所以开始怀疑是Redis引起的.

来自Facebook的一些MySQL运维经验

- - 运维派
每台机器都使用多实例的模型. 每个机器放多个实例,每个实例放多个DB. 一些信息可以参考: https://www.youtube.com/watch?v=UBHcmP2TSvk. 多实例之间没有进行资源隔离,这么做是让每个实例都能发挥最大性能. 目前大部分核心业务已切换成MyRocks引擎,在机器硬件配置不变的情况,约可节省一半机器.

从百万到十亿PV:Reddit的25条宝贵经验

- - IT经理网
自2005年至今,知名社交新闻网站Reddit的月页面浏览量完成了百万到十亿的转变,流量每15月翻一番,而Reddit的员工数量仍不满30,平均每位员工负责2400万PV. Reddit的高效率运营有两个支点:数以万计的志愿者以及失败中不断积累的宝贵经验. 前不久,Reddit前雇员Jeremy Edberg在RAMP会议上通过主题为“Scaling Reddit from 1 Million to 1 Billion–Pitfalls and Lessons”的演讲与人们分享了Reddit的宝贵经验.

每秒百万级流式日志处理架构的开发运维调优笔记 | Cloud

- -
荣幸之至,我们团队在实时日志分析、搜索项目中曾经应对过百万级的挑战,在这方面有长足的进步. 本文以笔记和问答的形式记录了我们曾经遇到过的实际问题及解决方案,而非小白式的大数据科普文章. 相信只有真正做过每秒近百万以上的实时日志处理业务,遇到过棘手问题,才能深刻感受我们当时越不过高坎的窘境与解决问题后的狂喜.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.