一个程序猿

最近一直在琢磨discuz的优化，想出一些数据缓存的策略：

index.php 部分数据已经进行了缓存，但需要全部缓存，只有当 页面刷新数/更新时间 >>>> 发帖数/更新时间 ，则有必要做此缓存，此处缓存更新最为频繁，适合做内存缓存，但 更新时间不宜太久，此时间根据首页更新频度确定。

forumdisplay.php 更新频繁，优化策略同上，只是更新频度略低于首页。

viewthread.php 回复更新频繁，内容更新频度低，适合做硬盘缓存。但分页部分不可做缓存，否则……

space.php 更新不频繁，适合做硬盘缓存。

faq.php 做个静态即可。

以上分析只是根据平时维护总结，临时脑子一蹦，未作具体分析，欢迎广大站长讨论试用。版权所有，欢迎盗版。

接此篇 http://www.sunboyu.cn/2009/11/05/discuz%E8%AE%BA%E5%9D%9B%E4%BC%98%E5%8C%96.shtml

最近一直在修改discuz，看到了很多问题，在跟系统工程部门合作的时候，也看到了很多比较优秀的解决方案，可以引入到系统中。

底下粗略讲述下已经做过的优化和可以着手进行的优化。

对于一个数据量比较大的论坛，首先是分表。posts表，threads表是必须要分的。可以按照forum表的fid进行分，也可以使用tid进行hash散列分布。分表带来的问题，显然是分页。我们进行排序的时候不可能去进行union查询，否则就失去了分表的意义。在这里，我们使用了一个支持排序的key-value型存储的小型数据库-Tokyo Tyrant（http://1978th.net/tokyotyrant/），用此数据库去同步threads表和posts表的数据，达到高速分页。（附：典型应用可以参见此文章 http://blog.s135.com/tcsql/ ）

随着数据表的膨胀，很多join联查必须进行拆分。分表可能强制我们去拆分联查，另外一些很变动不大的表，比如用户信息表的数据，使用率明显很高，变动不会太大，而使用key-value存储再合适不过。这时候，bdb和memcached是首选，我推荐使用bdb，可以持久存储于硬盘上，由用户更新资料触发更新，不必考虑过期和服务器重启的问题。这样可以减少太多的join联查，而节约数据库服务器的缓存。

随着静态文件的增长和访问量的增长，带宽浪费是一个值得考虑的问题。我们打开discuz的首页，静态文件要比php文件多好几倍，而每个文件都夹带了长长的cookie信息，因此，把这些cookie去掉显然会节约大量的带宽。discuz的文件结构还是很不错的，通常通过一个参数的配置或者全文替换就能完成这项工作。此应用，可以在新浪所有的图片上有所体现。

全文检索是mysql所不擅长的，因此附加一个好的全文检索方案很必须，我熟悉的方案：Lucene，sphinx，whoosh是我喜欢的几个全文检索的工具，对于discuz的负载，我感觉任何一个都能满足应用。在此方案上，设计一个完美的同步触发机制很重要。

还有很多问题，都在待发现中，部分问题已经解决，部分问题可以优化。discuz优化好，其实是个不错的产品。

很久没写点自己的小代码了，感觉手生。

最近一直在修改系统，并无太多原创的代码。其中修改了ucenterhome和discuz两套代码。

ucenterhome原来的队伍进行优化后，我又改进了分享功能。此功能虽然上线，功能也无大碍，但UE方面差强人意，主要是因为年前项目紧张，此项目投入人力并不多的原因。此功能修改，无详细的需求文档，也未进行详细的需求分析和业务逻辑设计，就匆匆开始了编码过程，结果就是：代码比较混乱，结构性比较差，升级和改进的潜力小。如果要改进，面临的结果就是重写。又因为uchome本身的设计结构，无论改写和重写成本都比较高。

因此，前期的规划是比较重要的，前期多想一点，后期就能节约更多的时间和精力。

这种做法马上应用到下一个项目中：discuz论坛的优化和功能改造。

前期对需求做了详细的分析，在中间不断的需求细化和明确，因此，功能和业务逻辑清晰，代码在修改的时候，保留了原来功能，只做了功能的分支。虽然前期的需求交流花费了较多的时间，但编码过程所花费的时间就很小了。

后者的流程才是以后要继续发扬的流程。

clean

用phpmyadmin写触发器的朋友，不知道有没有碰见这个问题：用pma导出的语句，死活倒不进去，mysqldump导出的，也不能用pma倒入。

反正问题多多，很令人头疼。

今天再次碰到这个问题后，偶然发现个问题，就是sql输入框下的一个小的内容：语句定界符。

平时导出sql，语句定界符默认是分号，而编辑触发器的时候，是两个斜杠//。

蹊跷就在这里，导入的时候使用的定界符必须跟倒出时候的定界符保持一致，否则就会出现错误。

问题发现后，老王是相当的高兴啊。

discuz论坛在国内非常流行，用户众多。优秀的用户体验和超强的负载，也赢得了众多的好评。

但discuz毕竟是为中小型网站设计，很容易达到性能的瓶颈。在最近对discuz的改造和表结构的分析，做了以下的探讨，来提升论坛的性能。

第一步，当然就是分表。
技术实力不太强的用户（严重依赖mysql的用户），分表是最直接的做法（当然，有些功能会损失）。

分析一个运营两年的discuz数据库，库表大概是十几个G左右，posts数据表已经几个千万。

首先可以拆分的，就是post表了。根据情况，post表可以分10张，百张，规则可以哈希，也可以阶段自增（分表主键使用tid（帖子id））。分完表，可以看到一排post_**的表，每个表的数据量降到百万以下，速度就无太大影响。

第二个可以拆分的，是threads表，此表分表，可以水平分割方式水平的分割，可以根据论坛版块id进行分表，这样可以使每个表的数据量减小，但这样也损失了一个功能：全站标题检索。

通过以上两个表的改造论坛的承载能力能迅速见长。

底下会讨论高级优化改造得方法，且听下次分解。

mysql没有一个像mssql的客户端去管理，所以有了PHPMYADMIN，管理mysql不再单纯依靠命令行，但PHPMYADMIN似乎不是那么万能，偶尔也会耍耍版本细节的脾气。

最近使用mysql触发器，不想使用命令行编辑，但phpmyadmin调试缺比较麻烦，原来想的是先建立一个空的触发器，然后修改，后来发现修改迁移问题多的要死，在老王同学的帮助下，经过几个晚上努力，整理出一些规律。

调试的时候，可以在空的触发器上逐条增加语句，一点一点调试，这样很容易定位问题，迅速修改。

迁移的时候，不能直接编辑触发器拷贝里边的代码，我用的phpmyadmin是2.11.9*版本的，生成的代码虽然他自己认，但一迁移就出了问题，我还没去阅读PHPMYADMIN的代码，不知道代码如何产生，但begin end里的内容大致相同，不同的是两头的辅助语句。

两头的内容跟版本密切相关，用mysqldump导出的语句做模板，把过程添加到里边，基本就没什么问题了。

不同版本的语法稍有出入，没有详细总结，总之掌握了调试的方法，解决问题速度就会提升。

使用触发器后，原来十几次的交互，一次就可以解决。我尝试了下出发器和存储过程，发现开发成本都差不多，复杂度也是类似的，所以没有用存储过程。

最近修改UCH，改得头大，对他的东西大概也熟悉个七八。

暂且不用说他的代码质量，逻辑或者完善程度，但说这个产品的发展路子，这肯定是个有市场的东西。

UCH是国内最早搞开源sns的了，而且搭配上discuz这个用户量很大的东西，迅速在国内铺开。

当然要说代码质量，那个惨，bug无数。基本做PHP的程序员，死都不愿意改它。

但是很多项目还是拿来了，为啥？因为他适合中国的用户，为啥适合？抄facebook？当然也有一定关系，关键呢，是因为东西出来的早。

产品迅速抢占市场是老戴在discuz闭源收费到开源免费的一个战略性转变，也正是这个转变，让discuz有了更加快速的成长。

bug？功能的欠缺？每天在discuz官方网站上可以看到无数的抱怨。吵得，骂的，一群一群的，但仍然阻止不了新版本接连不断的发布。

用户就是在这样不断的期望失望再期望再失望中逐渐培养出来的。

ecshop，我自认为做的很好，只可惜推出较晚，被南边的大头抢了先机。老戴的产品肯定会发展好的，因为他已经不是一个程序员。

php中的setcookie函数是有bug的，bug原理不太明白，不过底下这个方法可以避免这个bug