 |
| 北京总部: 4006-505-646 |
| 天 津 部: 4006-505-646 |
| 上 海 部: 4006-505-646 |
| 深 圳 部: 4006-505-646 |
| 广 州 部: 4006-505-646 |
| 重 庆 部: 4006-505-646 |
| 南 京 部: 4006-505-646 |
| 其它地区: 4006-505-646 | | |
|
 |
 |
让memcached和mysql更好的工作
这次是Fotolog的经验,传说中比Flickr更大的网站,Fotolog在21台服务器上部署了51个memcached实例,总计有254G缓存空间可用,缓存了多达175G的内容,这个数量比很多网站的数据库都要大的多,原文是A Bunch of Great Strategies for Using Memcached and MySQL Better Together,我这里还是选择性的翻译以及按照我的理解补充,感谢Todd Hoff,总能给我们一些学习的案例,从这里也能看出国外技术的开放态度,不似我们,其实就那么点小九九还藏着掖着,好了,进入正题。 一、关于memcached 还不知道这个?那你去面试的时候要吃亏了,赶紧去官方网站看一下http://www.danga.com/memcached/,另外google一下用法,硬盘总是太慢,把数据存在内存里面吧,如果你只有一台服务器,推荐用一下APC(Facebook在用)或者eaccelerator或者Xcache(国人开发的),这些产品单机效果更好,如果你需要分布式的缓存方案,那么用memcached吧。 二、memcached如何与mysql并肩作战? 通过数据库分片来解决数据库写扩展的问题把数据库分片,部署到不同的服务器上,免得只有一个主服务器,写操作成为瓶颈以及可能有的“单点故障”,一般的数据库分片主要是按照业务来分,尽可能的拆分业务,不相干的都独立起来做成服务也好 前端mysql和一堆memcached服务器来应付读的问题应用程序首先从memcached中获取数据,获取不到再从数据库中获得并保存在memcached中,以前看过一篇文章说好的应用95%的数据从memcache的中获得,3%的数据从mysql的query cache中获得,剩下2%才去查表,对比一下你的应用,差距有多远? 通过mysql复制(master-slave)来解决读的问题 首先mysql数据库通过master-slave读写分离,多个slave来应对应用程序读的操作。 三、为什么不用mysql的query cache? 我们都知道mysql有个query cache,可以缓存上次查询的结果,可实际上帮不上太多的忙,下面是mysql quety cache的不足: 只能有一个实例 意味着你能存储内容的上限就是你服务器的可用内存,一台服务器能有多少内存?你又能存多少呢? 只要有写操作,mysql的query cache就失效 只要数据库内容稍有改变,那怕改变的是其他行,mysql的query cache也会失效 mysql的query cache只能缓存数据库数据行 意味着其他内容都不行,比如数组,比如对象,而memcached理论上可以缓存任何内容,甚至文件^_^ 四、Fotolog的缓存技术 非确定性缓存你不确定你要的数据缓存中有没有,你也不知道是不是过期了,于是你就试探性的问memcached,我要的什么什么数据你那有吗?我可不要过期的数据啊,memcached告诉你说有并且给你,你就开心了,如果没有呢,你就要从数据库或者别的地方去获取了,这是memcached典型的应用。主要应用在:1.复杂的数据需要多次读取,你的数据库做了分片处理,从多个数据库中获取数据并组合起来是一个非常大的开销,你大可以把这些数据取出来之后存到memcached中 2.mysql query cache的一个好的替代方案,这样数据库其他部门改变了,只要自己没改变就没问题(注意数据库更新的问题,后面会提到) 3.把关系或者列表缓存起来,比如某个栏目下的多篇文章列表 4.被多个页面调用并且获取起来很慢的数据,或者是更新很慢的数据,比如文章浏览排行榜 5.如果cache的开销超过重新获取的开销,那么不要缓存它吧 6.标签云和自动建议(类似google sugest) 例如:当一个用户上传一个图片,这个用户的好友页面上都要列出这张图片来,那么把它缓存起来吧。 潜在问题: memcached消耗的主要是服务器内存,对CPU消耗很小,所以Fotolog把memcached部署在他们的应用服务器上(貌似我们也是这样),他们遇到了CPU搞到90%的使用率(怎么会那么高?哪出问题了吧)、内存回收(这是个大问题)等等问题。 状态缓存把应用服务的当前状态存在memcached中主要应用在:1.“昂贵”的操作,开销大的操作 | |
 |
| 上一篇:oracle因为日志错误无法打开 |
| 下一篇:修复MYSQL可能会使用到的实用程序列表 | |
 | | |