基于Discuz!&Memcache缓存实现的讨论


前言
在PHP+MySQL架构的站点中,本文重点从MySQL的角度去分析如何使Discuz!论坛(或者类似的PHP+MySQL架构的程序)应对大访问 量。同时给出一些使用Memcache去减轻MySQL压力的建议。其中很多数据是个人测试的结果,如有不同意见,敬请留言告之。另外由于个人思维的问 题,行文比较跳跃,特此声明!

系统分析
单纯的从MySQL的角度出发,单台MySQL的数据库负载到每天上亿次的操作(每秒大概1100次MySQL操作,然后乘以86400)应该不是非常困 难的事情。按照这个数据也就是说一个单MySQL服务器的论坛来说可以跑到2千万PV是不成问题的,我相信国内绝大部分的论坛都不可能做到每天2千万的 PV,但实际情况并不是如此。当论坛PV超过百万的时候一台WEB早已经不堪重负了。

就我手头的一些数据显示,目前的Discuz!论坛的基本服务器架构是前面Squid顶着,后面才是一台DB在撑着。这种架构中,web服务器压力 增大可以通过并行增加服务器解决,而MySQL压力却无处释放,在不考虑MySQL官方服务的情况下,我们通过合理的利用Memcache是可以达到减轻 MySQL服务器负载的。

可能会有朋友说我们可以对数据表进行分表(注:此处分表是指通过PHP程序去分表,比如pw,dv的分表)处理,但是当前的情况是一台DB服务器已经不能支撑当前的数据处理了,通过PHP对MySQL进行的分表依然不能减轻MySQL的负载。(注:本段文字针对已经成型的系统,如果是独立开发的系统在架构前期就进行数据的同步分区还是不错的。

还可能有朋友会说利用MySQL的主从构架,如果你提出这个问题,我就很明确的告诉你,回去看看手册吧。在Mysql Master/Slave 模式中,Slave主要是来备份数据的,只有当Master出现故障时,Slave才会接过Master的服务,对外部请求进行处理,直到Master恢 复正常。就是说:在Master/Slave中,要么是Master在服务,要么是Slave在服务,不会Master/Slave同时提供服务。使用MySQL主从依然不能有效的降低MySQL的负载。

或许你又会问我为什么不使用MySQL集群(MySQL Cluster),那可是白花花的银子啊,同等金钱的付出下,获得最大的收益才是王道。PS:说句题外话,MySQL手册中将MySQL集群解释为MySQL簇,不习惯。

其实在MySQL5.1中的MySQL分区(MySQL Partition)是个很好的东西,它允许根据可以设置为任意大小的规则,跨文件系统分配单个表的多个部分。实际上,表的不同部分在不同的位置被存储为 单独的表。我认为这个才是当前情况下,最积极有效的降低MySQL负载的解决方法之一。但是遗憾的是,这种MySQL分区的方式我个人没有使用过的经历,也不见有相当充分的案例表明它是稳定的或者不稳定的。所以我还在徘徊中。如果你知道,请麻烦告之!有朋友说腾讯是在用MySQL分区,但是遗憾的是我没有得到确切的数据。

好了分析总结了这么多种降低MySQL负载的方式之后,在用户环境需求等特定条件下,我得出结论在当前情况下,缓解Discuz!论坛的MySQL负载比较有效的方法就是使用Memcache!

使用Memcache的理由
1.Web Server(Lighttpd、Nginx据说都比Apache效率高好多,大家可以试用下)对CPU要求高,对内存要求低;而Memcached Server是对CPU要求低,对内存要求高,所以可以搭配使用。在对前端的Web Server上安装Memcached Server是可行的。
2.金钱金钱金钱,最少的付出,获得最大的收益。
3.简单简单简单,对于一个架构合理的系统来说,添加Memcache的支持可能只是一个批量处理文件的过程

Discuz!使用Memcache
1.在config.inc.php中增加

$memcachehost = '127.0.0.1';
$memcacheport = 11211;
$memcachelife = 60;

2.在include/common.inc.php中

$mem = new Memcache;
$mem->connect($memcachehost, $memcacheport);

3.修改include/db_mysql.class.php中的fetch_array、query这两个方法,并添加query_mysql方法,代码如下:

function fetch_array($query, $result_type = MYSQL_ASSOC) {
return is_resource($query) ? mysql_fetch_array($query, $result_type) : $query[0];
}

function query_memcache($sql, $type = '') {
global $mem,$memcachelife;

$key = md5($sql);
if(!($query = $mem->get($key))) {
$query = $this->query($sql, $type);
while($item  = $this->fetch_array($query)) {
$res[] = $item;
}
$query = $res;
$mem->set($key, $query , 0, $memcachelife);
}
return $query;
}

function query($sql, $type = '') {
global $debug, $discuz_starttime, $sqldebug, $sqlspenttimes;

$func = $type == 'UNBUFFERED' && @function_exists('mysql_unbuffered_query') ?
'mysql_unbuffered_query' : 'mysql_query';
if(!($query = $func($sql, $this->link)) && $type != 'SILENT') {
$this->halt('MySQL Query Error', $sql);
}

if(substr($sql, 0, 6) == 'SELECT') {
echo '<font color="red">Cache SQL</font>:<font color="green">'.$sql.'</font><br /><br />';
} else {
echo '<font color="red">Flash SQL</font>:<font color="green">'.$sql.'</font><br /><br />';
}

$this->querynum++;
return $query;
}

4.将需要使用Memcache缓存的SQL查询的代码由

$db->query(

修改为

$db->query_memcache(

注意并将

while($post = $db->fetch_array($query)) {

修改为

foreach($query as $post) {

没有while的$db->fetch_array可以不用修改。

下面代码有用得着的就拿去:

preg_replace("/while"([$]("w+)"s*"="s*[$]db->fetch_array"([$]query")")/is", "foreach("$query as "$""1)", $file);

回头放出个小工具批量替换下就可以了。
在EditPlus中可以这样替换:while"([$](.*) = [$]db->fetch_array"([$]query")")替换为foreach($query as $"1)
5.完成了,测试吧!~

参考资料
对Memcached有疑问的朋友可以参考下列文章:
Linux下的Memcache安装:http://www.ccvita.com/257.html
Windows下的Memcache安装:http://www.ccvita.com/258.html
Memcache基础教程:http://www.ccvita.com/259.html
Discuz!的Memcache缓存实现:http://www.ccvita.com/261.html
Memcache协议中文版:http://www.ccvita.com/306.html

后记
写完之后突然发现天已经要亮了,闷骚了一个晚上。个人的一些总结,欢迎留言探讨!


kimi At 2007-12-17 05:39:29 In Memcache.

评论(39 条评论)

  1. blankyao - 2007-12-17 11:47

    辛苦了!能坚持到天亮,不错 :)

  2. voff12 - 2007-12-17 21:45

    不错,sql(1-100)条数据,但如果其中有一个数据进行了更新,而其sql语句仍然一样,可能会读到脏数据。要一个update del,触发memcached的sql失效。

  3. kimi - 2007-12-17 22:24

    楼上正解,我那段代码只是最简单的利用Memcache减轻MySQL负载的一个小例子,对于一个论坛来说用1分钟的延迟时间减轻很多MySQL的压力,我认为是值得。当然程序可以做得更完美些(也就是更复杂些),去维护Memcache的key的时效性。

    我正在进一步的整理中,可以过短时间再来看看 :)

  4. zicky - 2007-12-18 13:50

    水水同志辛苦了
    虽然偶不懂这么高深的理论
    但是文章很不错啊
    小青年很有想法嘛

  5. lulu - 2007-12-19 22:16

    原来在闷骚这个啊

  6. dzfans - 2008-01-07 18:31

    能不能再完善些

  7. dzfans - 2008-01-07 19:58

    好象很多地方都涉及到用户权限的问题

    能不能举个实例比如
    index.php
    和forumdisplay.php的哪些地方能使用memeched的代码

  8. dzfan - 2008-01-07 23:30

    給您留的
    被您删除了,不知道为什么

  9. kimi - 2008-01-08 09:07

    没有被删除,只是还没有审核通过而已

    不设计权限判断的问题,我只是把从MySQL中取得的数据通过Memcached缓存了,该判断的权限还是PHP去做的,没有改变

  10. dzfans - 2008-01-08 13:15

    谢谢
    已经领悟到了

  11. dzfan - 2008-01-08 23:25

    怎样判断key已经过期?
    谢谢

  12. kimi - 2008-01-09 08:35

    key过期的时候,你是get不到的,比如$mem->get($key)返回FALSE,这时候就是key过期了

  13. dzfans - 2008-01-09 12:52

    明白了
    谢谢

    现在想把我自己的DZ改造下
    我去参考VBB弄

  14. leshou - 2008-01-18 14:07

    memcache的确能够有效的降低mysql的查询压力,但是优秀的缓存机制一定要考虑什么时候缓存,以及缓存过期的问题。要不然对用户来说就是非常不友好的。

  15. Fenng - 2008-01-18 19:46

    一片很有趣的文章。

    BTW: 1100次MySQL操作/S, 对于一台 DB 来说多少有些不现实.

  16. NinGoo - 2008-01-18 21:49

    在Master/Slave中,要么是Master在服务,要么是Slave在服务,不会Master/Slave同时提供服务

    这种说法是有问题的。master处理写,slave处理读的读写分离方式是可行的,实际上有不少架构就是这么来处理多并发访问的。

  17. kimi - 2008-01-19 07:16

    TO Fenng : 每秒1100次MySQL操作还是可以实现的。这个数据是针对Discuz!论坛的数据表的,我有数据,只是跑起来有些吃力,嘎嘎!

    TO NinGoo:其实我是想说对于写操作来说,主从不会同时起作用,这里写的是有问题。感谢提醒 :)

  18. NinGoo - 2008-01-19 13:49

    呵呵,对于论坛应用来说,读的压力应该要远远大于写的压力的吧

  19. tigris - 2008-01-20 02:14

    个人认为,主从库的有效分离是减轻mysql压力的较为有效的办法.
    memcache有的时候我觉得有点鸡肋的感觉,当然,并不是说memcache不行,而是像上面有位朋友所说的,cache的最高境界不在于它本身能减 少多少数据库查询,性能有多好,而是在于你如何根据自身情况去提高cache命中率以及控制缓存点(包括时间以及要缓存的部位)

    多台读库和少量写库的(M/S)搭配是大论坛或大社区有意义的尝试.而且,mysql数据库”集群”的成本只在服务器的价格与维护上,并没有软件上的成本.并不会有更多的金钱开销,呵呵.而且,在程序中实现读库与写库的不冲突也简单易行:
    对于数据同步的具体需求分为两种模式 —-
    1.如果只是考虑你写入后,用户立即读取这种情况,应该是完全来的及的,因为这个过程数据复制完成不超过一个毫秒
    2.如果你的同一个程序中 insert 或者 update 后,立即就有关联的其他查询,那么延迟会造成影响,所以需要在程序中加一个判断(我随手写的一个示意,不必深究代码,呵呵):
    while (! mysql_num_rows($result))
    {
    if ($times++ >= $timeout) break;
    usleep($read_delay_time);
    $result = mysql_query($query, $link_r) or die(”Query execute error: ” . mysql_error($link_r));
    }

    这样确保了读,写,感觉上还是很ok.当然数据库前面在放上memcache,效果自然更ok!
    胡乱写了点,大家凑合看…
    以上.

  20. 秋秋 - 2008-01-21 08:00

    好难理解啊。郁闷

  21. 草根网 - 2008-01-22 14:42

    好文,收藏至20ju.com

  22. 小草根 - 2008-01-28 22:07

    :)apc 这种缓存方式又怎么样呢?

  23. liuhl - 2008-02-14 10:30

    你没有考虑如果memcache服务器挂了的情况

  24. kimi - 2008-02-18 01:08

    在memcache服务器挂了的情况下,按照我上面文章中写的东西
    所有的内容都是直接从MySQL服务器直接查询了,因为链接Memcache的操作已经超时

    但是这样处理显然没有解决问题,在不考虑网速的情况下,虽然可以设置超时的时间但是其所带来的用户体验问题还是值得关注

    现在看来这篇文章写的很多粗陋的地方,所以决定过段时间重写下

  25. Tommy - 2008-02-24 21:18

    期待KIMI完善这个文章。先收藏了

  26. www - 2008-03-31 11:49

    每秒大概1100次MySQL操作,然后乘以86400,跑一天??服务器恐怕早就挂掉了,不要误导我们新手好不好?

  27. kimi - 2008-03-31 12:55

    @www 恩 每秒1100的并发是有点高了,但一台DB确实可以撑住,请记住Discuz!的所有数据库操作中,大概有三分之一是对cdb_session表的操作, 而且对于不同性质的论坛,数据库的访问压力侧重也是不同的。我觉着还是有一定参考价值的,不存在什么误导之类吧

  28. www - 2008-03-31 16:03

    请 记住Discuz!的所有数据库操作中,大概有三分之一是对cdb_session表的操作,那你何必搞得这么复杂,就只对cdb_session的 select做memcache,不就可以了么?所以呢。标题就不要起的这么大么。应该叫做:Discuz!的cdb_session表的 Memcache缓存实现。所以呢。还是误导。鉴定完毕。

  29. www - 2008-03-31 16:06

    你也不要想什么对策了。本来就是啊。其他的表确实也没怎么操作数据库。都生成缓存文件了。我没说错吧。所以请修改下标题吧。否则呆滞康会笑话你的哦。。嘎嘎

  30. www - 2008-03-31 16:11

    哦。不好意思。我说错了。对cdb_session的select做memcache,那就失去意义了。所以。标题是在做无用功。故。没有参考价值。嘎嘎

  31. kimi - 2008-03-31 16:47

    @www 你已经无敌了,Discuz!论坛程序的MySQL的一般瓶颈都是在cdb_posts cdb_members等数据表等的联合查询上,还有threads表的操作。尤其是对threads表进行memcache还是很有必要的。据我所知, 就有个很大的论坛是这样做的。

    另外我举例cdb_session是想说说明对于Discuz!的数据库进行优化,还是需要有侧重点的。

    本文写的也确实很稚嫩,去年12月我还没有发育的很好

    顺便再说下,你无敌了。

  32. www - 2008-03-31 17:16

    去年12月我还没有发育的很好,不知道是我无敌,还是你发育太快,照这样发育,也快无敌了。HOHO“`
    我请教个问题可以不,多少访问量,用memcache.如果Master/Slave这样的架构,还需要使用你这个咚咚么。这个问题请你发育好了,再回答我。嘎嘎

  33. www - 2008-03-31 17:34

    垃圾验证码,经常出’traffic’,你脑袋秀豆了么?
    哈哈。快换个验证码吧。。还有尽快回答陛下的问题。。。嘎嘎

  34. 嘟嘟鱼 - 2008-03-31 19:59

    看来不是我一个人说验证码有问题……

  35. www - 2008-03-31 20:16

    就是你一个人啊,ou是神仙。。嘎嘎

  36. kimi - 2008-03-31 23:36

    @www 如果按照Master/Slave之为了分流MySQL的压力,Memcache也是为了分流MySQL的压力,方案不一样,具体问题具体对待,也不存在哪一个架构就一定能够解决所有问题的。

    另外说,在我手头的一些文档和数据充分显示从百度,腾讯这些站点目前对于MySQL的负载的解决途径就是Master/Slave+ Memcache一起用,另外硬件的支持也很重要,比如目前bbs.xunlei.com就是做了raid5,然后把MySQL丢到内存里去做的负载减压

    @嘟嘟鱼 莫非验证码真的有问题么?可是我测试了几回都没问题啊~!

  37. kimi - 2008-03-31 23:37

    再PS下:迅雷官方论坛是也同样做了Master/Slave,没用Memcache

  38. phpgrid - 2008-04-16 17:29

    第一次接触大网站的具体优化,对新手确实很有参考价值,特别是后面的讨论!不知道你们是不是php程序员啊?

  39. kimi - 2008-04-16 19:15

    @phpgrid 基本上应该都是PHP,还有几个高手是DBA :)

posted @ 2008-05-05 16:34  hq5460  阅读(796)  评论(0编辑  收藏  举报