This Domain(Admin5.com) is for Sale:

让memcached和mysql更好的工作

时间:2009-04-11  来源:网络  更新时间:2009  作者:老K
QQ 收藏到MisterWong

  这次是Fotolog的经验,传说中比Flickr更大的网站,Fotolog在21台服务器上部署了51个memcached实例,总计有254G缓存空间可用,缓存了多达175G的内容,这个数量比很多网站的数据库都要大的多,原文是A Bunch of Great Strategies for Using Memcached and MySQL Better Together,我这里还是选择性的翻译以及按照我的理解补充,感谢Todd Hoff,总能给我们一些学习的案例,从这里也能看出国外技术的开放态度,不似我们,其实就那么点小九九还藏着掖着,好了,进入正题。

织梦内容管理系统

一、关于memcached

dedecms.com

  还不知道这个?那你去面试的时候要吃亏了,赶紧去官方网站看一下http://www.danga.com/memcached/,另外google一下用法,硬盘总是太慢,把数据存在内存里面吧,如果你只有一台服务器,推荐用一下APC(Facebook在用)或者eaccelerator或者Xcache(国人开发的),这些产品单机效果更好,如果你需要分布式的缓存方案,那么用memcached吧。 织梦好,好织梦

二、memcached如何与mysql并肩作战?

内容来自dedecms

通过数据库分片来解决数据库写扩展的问题把数据库分片,部署到不同的服务器上,免得只有一个主服务器,写操作成为瓶颈以及可能有的“单点故障”,一般的数据库分片主要是按照业务来分,尽可能的拆分业务,不相干的都独立起来做成服务也好 前端mysql和一堆memcached服务器来应付读的问题应用程序首先从memcached中获取数据,获取不到再从数据库中获得并保存在memcached中,以前看过一篇文章说好的应用95%的数据从memcache的中获得,3%的数据从mysql的query cache中获得,剩下2%才去查表,对比一下你的应用,差距有多远? 通过mysql复制(master-slave)来解决读的问题
首先mysql数据库通过master-slave读写分离,多个slave来应对应用程序读的操作。

三、为什么不用mysql的query cache? dedecms.com

  我们都知道mysql有个query cache,可以缓存上次查询的结果,可实际上帮不上太多的忙,下面是mysql quety cache的不足: dedecms.com

只能有一个实例
意味着你能存储内容的上限就是你服务器的可用内存,一台服务器能有多少内存?你又能存多少呢? 只要有写操作,mysql的query cache就失效
只要数据库内容稍有改变,那怕改变的是其他行,mysql的query cache也会失效 mysql的query cache只能缓存数据库数据行
意味着其他内容都不行,比如数组,比如对象,而memcached理论上可以缓存任何内容,甚至文件^_^

四、Fotolog的缓存技术

织梦内容管理系统

非确定性缓存你不确定你要的数据缓存中有没有,你也不知道是不是过期了,于是你就试探性的问memcached,我要的什么什么数据你那有吗?我可不要过期的数据啊,memcached告诉你说有并且给你,你就开心了,如果没有呢,你就要从数据库或者别的地方去获取了,这是memcached典型的应用。主要应用在:1.复杂的数据需要多次读取,你的数据库做了分片处理,从多个数据库中获取数据并组合起来是一个非常大的开销,你大可以把这些数据取出来之后存到memcached中

2.mysql query cache的一个好的替代方案,这样数据库其他部门改变了,只要自己没改变就没问题(注意数据库更新的问题,后面会提到) 织梦内容管理系统

3.把关系或者列表缓存起来,比如某个栏目下的多篇文章列表

织梦内容管理系统

4.被多个页面调用并且获取起来很慢的数据,或者是更新很慢的数据,比如文章浏览排行榜

内容来自dedecms

5.如果cache的开销超过重新获取的开销,那么不要缓存它吧 本文来自织梦

6.标签云和自动建议(类似google sugest)

dedecms.com

例如:当一个用户上传一个图片,这个用户的好友页面上都要列出这张图片来,那么把它缓存起来吧。 dedecms.com

潜在问题: 本文来自织梦

memcached消耗的主要是服务器内存,对CPU消耗很小,所以Fotolog把memcached部署在他们的应用服务器上(貌似我们也是这样),他们遇到了CPU搞到90%的使用率(怎么会那么高?哪出问题了吧)、内存回收(这是个大问题)等等问题。

织梦内容管理系统

状态缓存把应用服务的当前状态存在memcached中主要应用在:1.“昂贵”的操作,开销大的操作

2.sessions会话,Flickr把session存在数据库中,个人感觉还是存memcached比较“便宜”些,如果memecached服务器down掉了,那么重新登录吧。

本文来自织梦

3.记录用户在线信息(我们也是这样做的)

dedecms.com

确定性缓存对于某些特定数据库的全部内容,都缓存到memcached,有一个专门的应用服务来保障你要的数据都在memcached中,其他应用服务直接从memcached中获取数据而不去取数据库,因为数据库已经全部保存到memcached中并保持同步。主要应用在:1.读取伸展,所有的读取都从memcached中获得,数据库没有负载

2.”永不过期“(相对的)的数据,比如行政规划数据,变动很小吧 织梦内容管理系统

3.经常调用的内容 copyright dedecms

4.用户的认证信息 织梦好,好织梦

5.用户的概要信息 织梦内容管理系统

6.用户的参数设置

织梦好,好织梦

7.用户当前常用的媒体文件列表,比如用户的图片 织梦内容管理系统

8.用户登录,不走数据库,只走memcached(个人觉得这个不太好,登录信息还是需要持久化的,用类似BDB这样效果也不错) dedecms.com

使用方式:

织梦好,好织梦

1.多个专门的缓存池而不是一个大的缓存服务器,多个缓存池保障了高可用性,一个缓存实例挂掉了走其他的缓存实例,所有的缓存实例挂掉了,走数据库(估计数据库抗不住^_^)

织梦好,好织梦

2.所有的缓存池都用程序来维护,比如数据库有更新时,程序自动把更新后的内容同步到多个缓存实例中 dedecms.com

3.服务器重启之后,缓存要比网站先启动,这就意味着当网站已经启动了,所有的缓存都可用 copyright dedecms

4.读取的请求可以负载均衡到多个缓存实例中去,高性能,高可靠性

内容来自dedecms

潜在的问题: 织梦好,好织梦

1.你需要足够多的内存来存储那么多的数据 本文来自织梦

2.数据以行记录数据,而memcached以对象来存储数据,你的逻辑要把行列的数据转换成缓存对象 内容来自dedecms

3.要维护多个缓存实例非常麻烦,Fotolog用Java/Hibernate,他们自己写了个客户端来轮询

本文来自织梦

4.管理多个缓存实例会增加应用程序的许多开销,但这些开销相对于多个缓存得到的好处来说算不了什么

dedecms.com

主动缓存数据魔法般的出现在缓存中,当数据库中有更新的时候,缓存立马填充,更新的数据被调用的可能性更高(比如一篇新文章,看的的人当然多),是非确定性缓存的一种变形(原文是It’s non-deterministic caching with a twist.我觉得这样翻译怪怪的)。主要应用在:1.预填充缓存:让memcached尽可能的少调用mysql如果内容不展现的话。

2.“预热”缓存:当你需要跨数据中心复制的时候 织梦内容管理系统

使用步骤: 本文来自织梦

1.解析数据库更新的二进制日志,发现数据库更新时对memcached也进行同样的更新

织梦好,好织梦

2.执行用户自定义函数,设置触发器调用UDF更新,具体参考http://tangent.org/586/Memcached_Functions_for_MySQL.html 内容来自dedecms

3.使用BLACKHOLE策略,传说中Facebook也用mysql的Blackhole存储引擎来填充缓存,写到Blackhole的数据复制到缓存中,Facebook用这来设置数据作废以及跨国界的复制,好处是数据库的复制不走mysql,这就意味着没有二进制日志以及对CPU使用不那么多(啊?难道通过memcached存储二进制日志,然后复制到不同的数据库?有经验的同志在这个话题上可以补充。)

dedecms.com

文件系统缓存把文件直接缓存在memcached中,哇,够BT的,减轻NFS的负担,估计只缓存那些过于热门的图片吧。 部分页面内容缓存如果页面的某些部分获取起来非常费劲,以其缓存页面的原始数据还不如把页面的部分内容直接缓存起来直接调用 应用程序级别的复制通过API来更新缓存,API的执行细节如下:1.一个应用把数据写到某个缓存实例,这个缓存实例把内容复制到其他缓存实例(memcached同步)2.自动获得缓存池地址以及实例个数

3.同时对多个缓存实例更新

dedecms.com

4.如果某个缓存实例down掉了,跳到下一个实例,直到更新成功 织梦好,好织梦

整个过程非常高效以及低开销

织梦内容管理系统

其他技巧1.多节点以应对”单点故障”2.使用热备技术,当某个节点down掉了,另外一台服务自动替换成它的IP,这样客户端不用更新memcached的IP地址3.memcached可以通过TCP/UDP访问,持续连接可以减轻负载,系统设计成可同时承受1000个连接

4.不同的应用服务,不同的缓存服务器群 织梦好,好织梦

5.检查一下你的数据大小是否匹配你分配的缓存,更多请参考http://download.tangent.org/talks/Memcached%20Study.pdf 织梦内容管理系统

6.不要考虑数据行缓存,缓存复杂的对象 copyright dedecms

7.不要在你的数据库服务器上跑memcached,两个都是吃内存的怪兽

copyright dedecms

8.不要被TCP延迟困扰,本地的TCP/IP对内存复制是做了优化的 本文来自织梦

9.尽可能的并行处理数据 dedecms.com

10.并不是所有的memcached的客户端都是一样的,仔细研究你用的语言所对应的(好像php和memcached配合的不错)

织梦内容管理系统

11.尽可能的是数据过期而不是使数据无效,memcached可以设定过期时间

本文来自织梦

12.选择一个好的缓存标识key,比如更新的时候加上版本号

dedecms.com

13.把版本号存储在memcached中 织梦好,好织梦

  作者最后的感言我就不翻译了,貌似mysql proxy正在做一个项目,自动同步mysql以及memcached,更多参考http://jan.kneschke.de/2008/5/18/mysql-proxy-replicating-into-memcache 织梦好,好织梦

看完这篇,您有何感觉呢?

文章评论

共有位Admini5网友发表了评论 查看完整内容

站长之家wangzhan.dngz.net

24小时热门信息