Archive for the ‘PHP’ Category
Thursday, February 12th, 2009
前言：
关于Digg的架构，之前Fenng已经写过一篇Digg 网站架构的文章，Fenng在文章开头说“越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。”，其实是Fenng过谦了，我就是从DBA notes一点一滴开始学习的。
原文在Scaling Digg and Other Web Applications，Todd Hoff总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。
Digg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr...，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看http://shootout.alioth.debian.org/，看看而已不要用速度去衡量编程语言的优劣。
Digg的扩展战略：
扩展是有特殊性的，当已有的方案不能满足需求时，你需要根据自己的特殊需求来建立方案。要熟悉自己的业务需求，找出系统的短板，解决问题，避免过度优化。
编程语言不需要扩展，因为语言从来都不是瓶颈，把PHP提速300％不会是什么大问题。
去中心化，分布式处理高并发请求。
水平扩展，用更多更便宜的机器代替更高效更昂贵的机器。
数据库驱动的网站需要作水平分区和垂直分区扩展，水平分区就是把数据放到不同的机器上，比如按照时间划分：2009年的数据一组服务器，2009年的数据一组服务器，或者按照用户ID划分：每200W用户一组服务器；垂直分区把一个表分成多个表，每个表只包含一部分字段，可以按照业务分或者常用的“动静分离”，比如对文章计数的字段大可以和文章内容字段分开。
建立数据应用层，程序不要直接操作数据库分区，这样可以保持好的扩展性。这一点非常重要，如果没有数据应用层API，一旦对数据库分区做了修改，你的程序就需要大改了。程序的稳定性和持续性就不能保证。比较常见的MVC开发模式，数据层和逻辑层分开，一旦数据库底层改变了，只需要对数据层做简单的修改，不影响既有业务。
一致性、高可用性、分区容忍性（Partition Tolerance）三者只能取其二，具体的阅读http://camelcase.blogspot.com/2007/08/cap-theorem.html，一致性：每个人看到的都一样，哪怕当时就有更新；高可用性：部分故障不影响使用；分区容忍性：数据分区还能保持系统所有属性。
数据分区要求反常规化，这是在Digg是大问题，同样的数据要复制到多个对象上去，而且还好保持同步。
采用异步的队列架构，把任务放到队列中交由多台机器处理，而不是一次同步处理，关于异步任务处理可以阅读 Flickr - Do the Essential Work Up-front and Queue the Rest和The Canonical Cloud Architecture
icons和图片采用MogileFS存储，MogileFS是一个分布式的文件系统，由memcached作者开发，国内的好看簿也有使用MogileFS。
采用APC作为PHP加速器，Facebook用的也是这个，PHP5.30以后将自带APC加速器，同样的产品还有eAccelerator和Xcache，国内可能用eAccelerator的比较多，windows的版本我一般用这个网站编译的
缓存策略：永久性缓存和失效期缓存；基本不更新的内容采用文件缓存；动态缓存采用memcached；极少修改的数据采用APC缓存，APC不是分布式缓存，直接缓存的机器内存中，所以速度更快，适合缓存那些配置文件，比如MySQL的配置信息；缓存采用链责任模式，首先看PHP全局变量，如果没有就查APC，再没有就查memcached，最后没有就查数据库，这个觉得不太必要，你的缓存存在哪来你自己还不清楚阿。
Digg的推荐引擎是一个自定义的图形数据库，数据库最终保证一致性，先写如一个分区，然后再逐步写到其他的分区。在更新的过程中，可能取出来的数据不一致，是因为有不同的数据库分区处理，最终将会是一致。
MemcacheDB：性能革命性的一步
想象一下Kevin Rose，Digg的创建者，当前有4000个追随者，如果Kevin Rose一天digg一次，将会有4000个写操作，最热门的digg有最多的追随者，这会导致巨大的性能瓶颈：
你不能同时更新4000个追随者的帐号信息，幸运的是我们可以通过前面提到的异步队列方式解决。
Digg面临的海量写操作，如果平均每个人有100个追随者，一天就有3亿条写操作，平均到每秒有3000个写操作，每天有5GB的数据存储，在50～60台服务器之间有5TB的数据交换。
如果是MySQL的话估计早就挂了，Digg在笔记本上的测试是memcachedb每秒可以处理15000个写操作，memcachedb的测试结果表明每秒可以支持23000个写操作或者64000个读操作，足以应付Digg洪水般的请求。
memcachedb是一个分布式的kye-value型数据持久化解决方案，提供兼容memcached协议接口，由Sina工程师Steve Chu开发。
提到Digg为什么采用memcachedb，Digg的工程师给出的理由是：需要持久化缓存数据，与memcached协议兼容，Digg已经有很多业务应用了memcached，可以很方便的切换到memcachedb上去，开源。
后记：
很高兴的看到除了Sina，memcachedb又有一个超重量级的应用了，性能和可靠性都得到了极大的检验，大可放心应用生产环境中。我还说今年有空写个玩具版的类memcachedb项目，还是不要了，有时间还是去做些更有意义的事情，无谓重复发明。
Posted in Arch, PHP | No Comments »
Thursday, February 5th, 2009
早期的PHP开发者发现把PHP代码和HTML代码混在一起，维护起来非常的费劲，于是Smarty应运而生，将PHP代码和HTML代码分离，把MVC模式中的V(View显示)首先剥离，大大提高了程序的可阅读性和可维护性，于是有一大批的使用者，甚至到现在，如果你去找一份PHP的工作，如果不了解Smarty，估计够呛能拿到offer.
Smarty，这个PHP模板引擎曾经的代名词，最近的日子貌似不太好过，3.0Alpha出来了，不过很多人认为换汤不换药，更有甚者用回光返照来形容，真是英雄末路。
国外甚至有个No Smarty的网站，数典Smarty的种种"罪行"，然后给出了很多种替代方案(基本上是主流的PHP框架)，个人觉得不太公平，一个PHP模板引擎和一个完备的MVC框架能有可比性？
一个纯粹的PHP模板引擎在当前MVC当道的年代，难免不那么叫好，而且Smarty开发年代久远，有些设计确实不是太好，Smarty最早开发的时候估计是给页面制作人员(builder)来用的，以至于它的语法都和PHP不兼容，比如foreach语句，在Smarty里面就要用{foreach from=$foo item=bar}，可是套模板的工作基本上都是PHP程序员在做，不兼容PHP语法还需要重新去学习Smarty，而两种不同的风格足够让人抓狂。
如果是因为效率的问题放弃使用Smarty，大可不必，很多的网站还在用，比如我们，瓶颈不会出现在Smarty模板上，Smarty会把模板代码编译成PHP代码，下次调用的时候检测如果模板没有改动直接调用编译好的PHP代码，应该和原生的PHP代码差别不太大。而且Smarty自带了很多很有用的函数，比如转义，用起来还是很舒服的。
不过，最近Smarty项目已经从PHP官方移除了，访问http://smarty.php.net，提示Smarty is no longer a subproject of the PHP project, and has subsequently moved to its own domain: www.smarty.net，真是祸不单行。
Posted in PHP | No Comments »
Wednesday, January 28th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/bdb-cache/
做网站，好像大家都比较喜欢文件缓存，把那些读操作多写操作少的内容缓存成一个文件放服务器硬盘上，下次直接读取或者更新。针对每一个key缓存成一个文件，当需要缓存的内容多的时候，文件数也就相应的多，这么多文件的同步和备份都是大问题，数据的可靠性也无从保证。
可是为了"效率"，我们也忍了，但文件缓存的效率真的好吗？有没有更好的方案？当然，memcached是很好的解决方案，今天这里测试另外一种方案：使用Berkeley DB作为网站数据缓存方案。
测试环境：CentOS 5.2，Core2 T5500@ 1.66GHz，1.5G内存，Ext3文件系统，apache 2.2.3，php 5.2.8 with php_dba
数据初始化：为了不至于在一个目录下文件数目过多，文件缓存分了两级hash目录，初始化数据数10万条。
/**
* 初始化缓存
*
* @param int $limit
*/
function init_cache($limit = 100000)
{
$str = 'good good study,and day day up.';
$bdb = dba_open('./bdb.db', 'c', 'db4');
for ($i = 0; $i < $limit; $i++)
...
Posted in PHP | 2 Comments »
Friday, September 12th, 2008
About OpenSlopeOne
OpenSlopeOne is an implementation of Slope One based on PHP&MySQL, it's an open source project under GPL V3.
It aims to a fast way to use Slope One with PHP&MySQL, and it can handle tons of data.
It's localed on Google Code:
http://code.google.com/p/openslopeone/
You can get the latest code here:
svn checkout ...
Posted in Data Mining, MySQL, Open Source, PHP | 1 Comment »
Wednesday, September 3rd, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/09/slope_one/
推荐系统最早在亚马逊的网站上应用，根据以往用户的购买行为，推荐出购买某种产品同时可能购买的其他产品，国内做的不错的当当网,有时候买书，它总能给我推荐出我感兴趣的其他书来，也算是技术极大的促进了销售。
一般的协同过滤算法，首先是收集用户对事物（产品）的评分情况，一种直接对某本书，或者某个歌曲打分，另种是隐性的打分，比如商务系统中，购买了表示打2分，浏览了打1分，其他的0分。我比较看好隐性打分，因为直接打分需要用户的参与程度比较高，很多网站都在内容页中留一个打分的按钮，从1～5选一个，我可能喜欢这篇文章，可我哪里知道我喜欢的程度是几分啊，还要我去思考，而网站设计中一条很重要的原则是:Do not let me think!，于是我就胡打一个分数或者不打，而隐性的打分则不同，只有你喜欢的图书你才会购买，只有你喜欢的歌曲才会听多次。
收集好用户的打分之后，通过最近邻搜索到和某个事物或者某个人特征或者兴趣相近的其他事物或者人，最近邻搜索算法一般是皮尔森相关系数（Person Correlation Coefficient）、余弦相似性（Cosine-based Similarity）以及调整余弦相似性（Adjusted Cosine Similarity）。关于余弦定理在数据挖掘中的应用，google黑白报有过介绍，可以参考数学之美 系列 12 - 余弦定理和新闻的分类。
剩下的工作就是根据最近邻集进行推荐了。
最近邻集的运算相对来说成本比较高，尤其是大量数据的时候，今天和大家分享的是一种简单高效的协同过滤算法：Slope one
基本原理
用户
对事物A打分
对事物B打分
X
3
4
Y
2
4
Z
4
?
用户Z对事物B的打分可能是多少呢？股票上有个说法是平均值可以掩盖一切异常波动，所以股票上的各个技术指标收拾不同时间段的平均值的曲线图或者柱状图等。同样的，Slope one算法也认为：平均值也可以代替某两个未知个体之间的打分差异，事物A对事物B的平均很差是：((3 - 4) + (2 - 4)) / 2 = -1.5，也就是说人们对事物B的打分一般比事物A的打分要高1.5，于是Slope one算法就猜测Z对事物B的打分是4 + 1.5 = 5.5
是不是非常的简单？
加权算法
有n个人对事物A和事物B打分了，R(A->B)表示这n个人对A和对B打分的平均差（A-B）,有m个人对事物B和事物C打分了，R（C->B）表示这m个人对C和对B打分的平均差（C-B），注意都是平均差而不是平方差，现在某个用户对A的打分是ra，对C的打分是rc，那么A对B的打分可能是：
rb = (n * (ra - R(A->B)) + m * (rc - R(C->B)))/(m+n)
开源的Slope one的程序包
Python
http://www.serpentine.com/blog/2006/12/12/collaborative-filtering-made-easy/
Java
http://taste.sourceforge.net/
http://www.daniel-lemire.com/fr/documents/publications/SlopeOne.java
http://www.nongnu.org/cofi/
PHP
http://sourceforge.net/projects/vogoo
http://www.drupal.org/project/cre
http://www.daniel-lemire.com/fr/documents/publications/webpaper.txt Slope one算法作者写的，简单明了，强烈推荐。
Erlang
http://chlorophil.blogspot.com/2007/06/collaborative-filtering-weighted-slope.html
C#
http://www.cnblogs.com/kuber/articles/SlopeOne_CSharp.html 国人写的C#版本
T-SQL
http://blog.charliezhu.com/2008/07/21/implementing-slope-one-in-t-sql/
还有一些其他语言的版本，请参考http://en.wikipedia.org/wiki/Slope_One，即将面世的，居于PHP & Mysql的Slope one算法实现将会在http://code.google.com/p/openslopeone/开源出来，主要优化的是海量数据以及分布式处理，目前在我的笔记本上（迅驰＋1.5G内存），对440W打分记录进行测试，单一线程，3小时47分处理完。速度还算是不错了，最近工作实在太忙了，等我整理好会开源出来放在上面的地址。过几天会有一篇我的算法的详细介绍，盼诸位批评指正，共同学习，共同进步。
Posted in Data Mining, Open Source, PHP | 6 Comments »
Wednesday, August 20th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/learn_zend_framework_zend_controller/
前一段时间一直在看Zend Framework方面的东西，参照着设计模式阅读Zend Framework结构收获良多，我将以一系列的文章和大家一起探讨Zend Framework（文中将以ZF代替Zend Framework）。
ZF是Zend公司开发的一套PHP快速开发框架，类似的框架还有cakephp、codeigniter等，当然国内的也有一些这方面好的尝试，如FleaPHP&ThinkPHP，每个框架都有自己的特色，我这里只说一下ZF，ZF过于强大了以至很多人都觉得ZF是不是臃肿了？其实ZF在松散耦合方面做的非常的好，ZF的各个模块基本上都可以调出来单独使用，这就是很多人觉得ZF是PEAR2的原因。ZF的学习成本相对其他框架来说要高很多，当然也可以什么了解一点，然后写出只值“一点”的程序来，国内用ZF的大压力项目有6.cn，可惜Michael一直没有时间给我们分享更多，了解ZF可以关注一下phpeye，站长HaoHappy给我们贡献了ZF的中文手册，实在是一件功德无量的事情。
Zend Framework整个框架的核心的Zend_Controller，所以要学习ZF的同学最好把手册中Zend_Controller部分多看几遍，我们进入正题吧。
一、MVC的设计模式
一个良好的应用结构一般分为三层：Model层（一般是数据层）、View层（表现层）和Controller层（控制层或者说是逻辑层），底层数据和逻辑分离、逻辑与前台展现分离，这样的话程序的伸展性和可维护性都大大提高，下面的例子会将一个很糟糕的设计转化成一个PHP的MVC设计.
先看糟糕的程序吧:
<?php
$userID = 9527;
/**
* 开始连接数据库,查询数据库等等的操作,类似:
* $db = mysql_connect('host', 'user', 'pwd');
* mysql_select_db('dbname');
*/
// 假设最后你获得了用户名称
$userName = '超群.com'
?>
<!-- 开始显示用户名称 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><?php echo $userName;?>,你好</title>
</head>
<body>
Hell,<?php echo $userName;?>
</body>
</html>
我们会看到一个文件里面混合着PHP和HTML代码，如果美工修改了模板或者业务逻辑稍有变化都需要改大量的程序，而且还有一个致命的问题：代码复用，如果另外的地方也需要获得用户名称，你是不是要重新写一遍同样的代码呢？记住：重复代码是邪恶的。
然后再看一下MVC的设计,我们把业务划分为三块:获得用户名称(数据层)、控制用户名称显示(控制层)、用户名称显示模板(表现层)：
数据层：
控制层：
表现层：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>{$userName},你好</title>
</head>
<body>
Hell,{$userName}>
</body>
</html>
这个例子非常简单，但确能给各位一个关于MVC在PHP的呈现结构。
二、Zend_Controller
一般的应用手册上面已经写的很详细了，建议仔细阅读手册，我这里想讨论的是不用mod_rewrite然后还想用传统的目录结构怎么处理？我想很多人的困在这里，手册上推荐的目录结构是：
application/
controllers/
IndexController.php
...
Posted in PHP | No Comments »
Tuesday, August 12th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/memcached_work_with_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.“昂贵”的操作，开销大的操作
2.sessions会话，Flickr把session存在数据库中，个人感觉还是存memcached比较“便宜”些，如果memecached服务器down掉了，那么重新登录吧。
3.记录用户在线信息(我们也是这样做的)
确定性缓存对于某些特定数据库的全部内容，都缓存到memcached，有一个专门的应用服务来保障你要的数据都在memcached中，其他应用服务直接从memcached中获取数据而不去取数据库，因为数据库已经全部保存到memcached中并保持同步。主要应用在：
1.读取伸展，所有的读取都从memcached中获得，数据库没有负载
2.”永不过期“(相对的)的数据，比如行政规划数据，变动很小吧
3.经常调用的内容
4.用户的认证信息
5.用户的概要信息
6.用户的参数设置
7.用户当前常用的媒体文件列表，比如用户的图片
8.用户登录，不走数据库，只走memcached（个人觉得这个不太好，登录信息还是需要持久化的，用类似BDB这样效果也不错）
使用方式：
1.多个专门的缓存池而不是一个大的缓存服务器，多个缓存池保障了高可用性，一个缓存实例挂掉了走其他的缓存实例，所有的缓存实例挂掉了，走数据库（估计数据库抗不住^_^）
2.所有的缓存池都用程序来维护，比如数据库有更新时，程序自动把更新后的内容同步到多个缓存实例中
3.服务器重启之后，缓存要比网站先启动，这就意味着当网站已经启动了，所有的缓存都可用
4.读取的请求可以负载均衡到多个缓存实例中去，高性能，高可靠性
潜在的问题：
1.你需要足够多的内存来存储那么多的数据
2.数据以行记录数据，而memcached以对象来存储数据，你的逻辑要把行列的数据转换成缓存对象
3.要维护多个缓存实例非常麻烦,Fotolog用Java/Hibernate，他们自己写了个客户端来轮询
4.管理多个缓存实例会增加应用程序的许多开销，但这些开销相对于多个缓存得到的好处来说算不了什么
主动缓存数据魔法般的出现在缓存中，当数据库中有更新的时候，缓存立马填充，更新的数据被调用的可能性更高（比如一篇新文章，看的的人当然多），是非确定性缓存的一种变形(原文是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
3.使用BLACKHOLE策略，传说中Facebook也用mysql的Blackhole存储引擎来填充缓存，写到Blackhole的数据复制到缓存中，Facebook用这来设置数据作废以及跨国界的复制，好处是数据库的复制不走mysql，这就意味着没有二进制日志以及对CPU使用不那么多（啊？难道通过memcached存储二进制日志，然后复制到不同的数据库？有经验的同志在这个话题上可以补充。）
文件系统缓存把文件直接缓存在memcached中，哇，够BT的，减轻NFS的负担，估计只缓存那些过于热门的图片吧。
部分页面内容缓存如果页面的某些部分获取起来非常费劲，以其缓存页面的原始数据还不如把页面的部分内容直接缓存起来直接调用
应用程序级别的复制通过API来更新缓存，API的执行细节如下：1.一个应用把数据写到某个缓存实例，这个缓存实例把内容复制到其他缓存实例（memcached同步）
2.自动获得缓存池地址以及实例个数
3.同时对多个缓存实例更新
4.如果某个缓存实例down掉了，跳到下一个实例，直到更新成功
整个过程非常高效以及低开销
其他技巧1.多节点以应对"单点故障"2.使用热备技术，当某个节点down掉了，另外一台服务自动替换成它的IP，这样客户端不用更新memcached的IP地址
3.memcached可以通过TCP/UDP访问，持续连接可以减轻负载，系统设计成可同时承受1000个连接
4.不同的应用服务，不同的缓存服务器群
5.检查一下你的数据大小是否匹配你分配的缓存，更多请参考http://download.tangent.org/talks/Memcached%20Study.pdf
6.不要考虑数据行缓存，缓存复杂的对象
7.不要在你的数据库服务器上跑memcached，两个都是吃内存的怪兽
8.不要被TCP延迟困扰，本地的TCP/IP对内存复制是做了优化的
9.尽可能的并行处理数据
10.并不是所有的memcached的客户端都是一样的，仔细研究你用的语言所对应的（好像php和memcached配合的不错）
11.尽可能的是数据过期而不是使数据无效，memcached可以设定过期时间
12.选择一个好的缓存标识key，比如更新的时候加上版本号
13.把版本号存储在memcached中
作者最后的感言我就不翻译了，貌似mysql proxy正在做一个项目，自动同步mysql以及memcached，更多参考http://jan.kneschke.de/2008/5/18/mysql-proxy-replicating-into-memcache
后记：前几天，把Flickr架构(一)这篇文章发在PHPChina那的原创板块，居然被管理员当成软文给删掉了，难道就因为我保留了版权信息？匪夷所思。
Posted in Arch, MySQL, PHP | 2 Comments »
Thursday, July 31st, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/07/ffmpeg-php-install-on-centos
最近的一个项目，要批量获取音频文件（包括mp3、wma等格式）的播放时长，由于项目整体是Lamp结构的，所以最佳的方案就是能找到这么一个PHP扩展能提供这样的功能接口。
我们用到的开源项目是http://ffmpeg-php.sourceforge.net/，ffmpeg的php扩展，下面是ffmpeg-php在linux下的快速安装。
安装需求：
ffmpeg-0.4.9_pre1 or higher.
php-4.3.0 or higher *需要有php-dev包，如果服务器上没有，可以通过yum install php-dev进行安装
gd-2.0 or higher (the version of GD bundled with PHP works too) *这个一般都有吧
编译安装ffmpeg非常的麻烦，还好我们找到了一个yum源可以方便的安装ffmpeg以及ffmpeg-dev，下面是步骤：
vi /etc/yum.repos.d/dag.repo
输入：
[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
导入Dag的RPM_GPG_KEY,否则提示没有key无法安装
wget http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt
rpm -import RPM-GPG-KEY.dag.txt
安装ffmpeg&ffmpeg-php
yum install ffmpeg ffmpeg-devel
没有找到ffmpeg-php的安装包，所以只能编译安装了，下面是编译步骤：
wget http://internap.dl.sourceforge.net/sourceforge/ffmpeg-php/ffmpeg-php-0.5.1.tbz2
tar -xjf ffmpeg-php-0.5.1.tbz2
phpize
./configure
make && make install
安装完之后，把ffmpeg.so（我的位置是/usr/local/lib/php/extensions/no-debug-non-zts-20060613/） 复制到php的扩展目录下，在php.ini中加入
extension=ffmpeg
ffmpeg-php的api参考http://ffmpeg-php.sourceforge.net/doc/api/
写了一个简单调用程序
在audios目录下放了三首mp3歌曲，用ab简单测试了一下结果（测试机配置巨差），下面是测试结果，处理结果大概是80首/s，还是可以接受的。
[root@centos ffmpeg]# ab -n 5000 -c 100 http://*****/ffmpeg/mp3timer.php
This is ApacheBench, ...
Posted in PHP, 默认分类 | 3 Comments »