Tag: memcache

  • 关于“facebook的memcached实战”小记

    上周挤到QCon的会场里,听了两场 —— Facebook的Memcached实战,以及Twitter 的可伸缩性数据架构。当时对facebook超大规模使用memcached印象很深刻,只可惜到现在也没见到这个的ppt。平时用php比较多,因此听闻同样使着php的facebook讲memcached,有些小小的感触,记录下来。 更高效的序列化函数 php有两个memcache扩展,默认都是使用php自带的序列化函数serialize来存储数组或对象。但是serialize最为人诟病的就是速度慢,序列化之后占用空间大。由于facebook已经在memcached里保存了200T字节的数据,因此序列化函数即便作出的百分之一的优化对它来说都是个不小的收益。他们发粪涂墙在thrift的binary协议基础上搞出了一个fb_serialize,据称这个序列化方法能快上3倍,快倒算了,还能节省30%空间, 200T字节的数据能节省出30%,简直就是传说中的银弹啊,这让php官方的开发人员们情何以堪? facebook目前已经开源了thrift,其中自带了一个thrift协议的php扩展,但是这些代码里没有找到传说中的fb_serialize,我倒是从最近他们放出来hiphop-php里找到了这部分代码,哪位大侠去扒拉扒拉弄出来做成php扩展造福广大群众? 作为备选方案,我推荐igbinary,这也是一个binary的序列化方法。在上次的测试结果中,它甚至能节约50%的存储空间,速度也是稳超php原生的序列化方法,搞不好facebook换了这个序列化方法能省下更多的内存来? 节约每个item的存储空间有什么好处?我个人认为一个是省钱,另外一个就是能够带来速度上的提升。我们平常碰到稍大一点的item都得用gzip压的妥妥贴贴的才送到memcached里,网络传输的开销小了,这是实实在在的性能提升。何乐而不为? mcproxy mcproxy = memcached + proxy。facebook的机房遍布各洲,利用mcproxy来进行跨机房的同步或分发,全球制霸,指着太阳就能等到那天了。一般的互联网企业还真用不上这玩意,规模还没上去的时候,这些乱七八糟的只会拖后腿。facebook还没开源mcproxy,但是我找到两个替代品: memagent is a simple but useful proxy program for memcached servers. moxi = memcached + integrated proxy 从项目描述来看,moxi最接近facebook介绍的mcproxy,成熟度也比较高。 数据的一致性 Marc Kwiatkowski在会场上用大篇幅的ppt和大量的动画来阐述这个问题,他们用了很多额外的手段来解决在跨机房情况下因为延时问题造成的脏数据。这一段看着挺晕,但是我们联想到facebook用到的多级cache技术: 本地全局变量 + apc + memcache,不难理解这样做颇有些道理,这相当于用memcache实现了一个版本控制系统。 我还是很晕这段ppt。

  • Memcache的备忘

    把memcache使用时的一些细节记录下来. 用memcache保存session的例子,非常简单 <?php $session_save_path = “tcp://$host:$port?persistent=1&weight=2&timeout=2&retry_interval=10, ,tcp://$host:$port “; ini_set(‘session.save_handler’, ‘memcache’); ini_set(‘session.save_path’, $session_save_path); ?> memcache每一个item上限是1M,注意不要超出上限 memcache本身并不支持namespace,但是可以通过一些手段模拟出namespace的效果来,见Memcache 中模拟 namespace 刚接触memcache的时候,可能会写出这样的代码来 $zhang = $memcache->get(‘key1’); $li = $memcache->get(‘key2’); $wang = $memcache->get(‘key3’); 这种写法实际运行效果是 get(key1) – 客户端发出请求 – 服务器端查询 – 客户端获取 get(key2) – 客户端 – 服务器端 – 客户端 get(key3) – 客户端 – 服务器端 – 客户端 … 如此一来,会有三次客户端和服务器端交互的过程。但是如果用批量查询的方法,就只有一次交互的过程。比如: $all = $memcache->get(array(‘key1’, ‘key2’, […]

  • 使用memcache的几个优点

    最近在3个项目中都有用到memcache,这东东确实有出人意料的上佳表现,优点不少。 稳定,几个月以来,一同装上去的apache已重启过多次,这期间memcache一直踏踏实实干活,一点都不需要中途加油。 配置简单,那是相当的简单,几乎不用配置,一个命令行的守护进程跑下来,就可以不管了 多机分布式存储,每个前端机都能匀出一些内存来跑memcache,这些内存加在一起,总大小也是相当的客观,能够应付足够多的缓存数据,如果开启了memcache的压缩选项MEMCACHE_COMPRESSED,存储量还能有进一步提升。 速度快,这个论点需要数据支持,俺手头之前有一些不同数据量级下set/get的速度对比,但是这里不方便列出来 以上,俺认为memcache是前端缓存一个漂亮的解决方案

  • Memcache的分布式应用

    早就听说memcached是一个不错的分布式内存缓存系统,做了些功课想把这memcache用到实际当中来.因为一个好的缓存系统,能给web应用带来不小的性能提升.做了一些功课之后,做了下面几点总结: memcache适合与web server安装在同一server上 memcache可以在n个端口开n个进程,如果和web server在同一机器的话,还能减少网络开销. 配置简单,启动一个进程就行了,免去了配置文件 我更关心的是,memcache的分布式应用应该如何部署.带着这个问题,我在各搜索引擎上做了进一步的功课.最初找到的办法是,首先启动n个memcache进程,这些进程可以在不同的server的不同端口上. 然后使用perl的api可以方便的一次链接多个memcache,存储读取机制不明.不久找到php的一个MemcachedClient类,基本上就是perl里api的再实现.它使用的fscokopen或者socket系列function来直接读取memcache—-这说明只要清楚memcache的网络协议,你甚至不用装什么php的memcache extenstion.看了这个类的实现,基本上弄清楚,它的分布式应用差不多就是将不同的key保存在不同的memcache daemon,不会保留多个副本,也就不存在多memcache同步的问题了. 过了不久俺又有发现,在最新的php手册上找到了memcache::addServer()这方法,它就是为分布式应用而产生的,有了这个支持的话,php的代码就更简单: <?php $memcache_obj = new Memcache; $memcache_obj->addServer(‘memcache_host’, 11211); $memcache_obj->addServer(‘failed_host’, 11211); $stats = $memcache_obj->getExtendedStats(); print_r($stats); ?> 看来php手册也要与时俱进啊,最好是能够直接使用英文版,否则也不会走这么多弯路了:) 官方站点 http://www.danga.com/memcached/