设为首页 收藏本站
查看: 1266|回复: 0

[经验分享] memcache的key的管理

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2014-3-31 10:16:47 | 显示全部楼层 |阅读模式
一,在说出我的困惑时,先罗嗦一下memcache
memcache是一个高性能的分布式的内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。Memcache是danga.com的一个项目,最早是为 LiveJournal 服务的,最初为了加速 LiveJournal 访问速度而开发的,后来被很多大型的网站采用。目前全世界不少人使用这个缓存项目来构建自己大负载的网站,来分担数据库的压力。起初作者编写它可能是为了提高动态网页应用,为了减轻数据库检索的压力,来做的这个缓存系统。它的缓存是一种分布式的,也就是可以允许不同主机上的多个用户同时访问这个缓存系统, 这种方法不仅解决了共享内存只能是单机的弊端,同时也解决了数据库检索的压力,最大的优点是提高了访问获取数据的速度!基于memcache作者对分布式 cache的理解和解决方案。 memcache完全可以用到其他地方 比如分布式数据库, 分布式计算等领域。
二,memcahce的key如何关理,更合适

大家都知道,memcache缓存的数据放在内存中,用的key=>value的方式,来查找和更新value的值,从这里可以看出对于key的管理直接影响到value的值,影响到内存的利用率和效率,以及程序员写代码的难度,怎么样才做到最优化呢,这也是我一直思考的问题,我想了二种方案,但是觉得都不完美。先说一说我的方案吧
1,对单表进行缓存
优点:
a,对于key的维护很简单
key对应一张表的数据,所以key是根这张表有关的sql或者其他。如果是我,我会用取整表的sql语句经过hash后来当key。注意一点hash过程中,如果sql有一点点不同,hash出来就会不同,包括空格,字母大小字等。所以建议将sql建行封装。
b,就同一张表来说,内存中不会有重复数据
缺点:
a,加大程度开发难度
举个例子来说,如果我想对二张表或者更多表,进行联合查寻时,正常情况,我可以用left join或者其他来进行查寻就行了,也许一个sql语句就能搞定,但是现在对单表进行缓存时,就要把单表的数据取出来,用php的循环进行查找数据了。这样对于程序员来说是一件很痛苦的事。
b,加大系统负担,影响memcache效果
这个缺点很明显,因为多表操作时,用php的循环套循环,会加大系统负担,如果一张表有几百M, 另一张表也有几十M,你用php循环来把你想要的数据找到时,所花的时间也许比直接用联合查寻访问数据库所用的时间更长,这样我就没必要用memcache,这个也是致命缺点。
个人觉得这种对key进行管理的方式,比较适合写入,或者更新操作比较多的网页,因为对于key的update很容易,key根表名是一一对应关系,这样找起来就容易多了。
2,对数据段,数据点进行缓存
优点:
a,查找效率高
我想memcache设计的目的也就是这个了,通过key找到value,就是我们所要的数据,不要进行任何处理。不要对数据库进行操作,不要用php循环来取数据,可以说省了很多事情。
b,开发效率高
对于程序员来说,以前是怎么开发现在还怎么开发,就当memcache不存在就行了。
缺点:
a,内存利用率差
举个例子来说吧,数据段A和数据B有重复数据,内存中的二个数据段都会包括相同的数据,这对内存利用率来说是不好的。如果你的memcach所占内存是1G的话,并且你用这种方法来进行key的管理的话,1G内存中重复数据有可能占了一半。
b ,key的管理难
为什么对key的管理难呢,因为key受很多因素的影响。不像上面的那种方法,key和表名是一对一关系。在这里,key受表名,可能是多个表名,where后面所带的参数所影响,所以管理起来相当的不方便。当你更新一个数据时,入库的同时,key对应的value就要相应的改动,不然用户会认为网站有bug。根这张表有关系的key很多,很有可能你就没有把所有key对应的value都更新掉
个人觉得这种对key的管理方式比较适合,读取比较多的,写入比较少的网站,如果经常写入的话,更新key所耗的资源也很大,不如用上面的那一种对key的管理方式。
如果读取比较大,写入也比较频繁呢,怎么办呢,个人觉得这二种方法都不合适,如果非要做个选择的话,我会选择第二种,有没有别的方法来,综合上面二种方法的优点,去除上面二种方法的缺点的方法呢。思考中


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-16514-1-1.html 上篇帖子: memcache 的总体轮廓一览 下篇帖子: memcache+apache+tomcat(提供软件包)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表