一个程序猿

最近一直在折腾dz的sessions表优化。经过某群好友的各种方法提示和一些高数据量用户论坛的鼎力支持，总结以下优化方案。部分方案是在某些论坛正在使用的，部分方案是我发散思维总结的，没有经过大数据量和大负载下的应用，只是作为一个备选的方案，当然欢迎朋友们拿去实践。

1、分库

这个方法至少两三个注册用户百万级至千万级的论坛在使用。实施也比较简单，只需要把sessions表放在其他的库中，跟论坛主库分离，这样，就可以用多台服务器来分担论坛压力。sessions表查询的地方，如果直接查询，则连sessions表所在的库，如果是联查，则分别查询后，合并插叙结果。

2、砍功能

这个方法虽然不实用，但的确有效。仔细看看dz的一些sql语句，就知道砍掉某些功能摆脱sessions表的约束，性能会有多大的提高。砍功能，最终还是为了提升性能。但如果不砍功能又提升性能，才是终极目的。此方法适用于对某些统计功能要求不高的论坛使用。

3、memcached存储sessions，异步统计用户的在线数据

此方法其实还是砍掉了论坛的用户在线统计功能而独立开发一套统计系统。此思路来源于我们的统计服务器。如果统计服务器已经统计了部分信息，就没必要再去耗费大量的sql效率去进行统计。当时我们负责统计的吴同学正好也要开发一套针对不同系统的统计代码，我可以直接把要统计的数据提交给统计服务器，再由统计服务器返回统计结果。以异步的方式来统计，化解dz sessions表的性能瓶颈。而统计信息的异步提交，可以提交到本地数据库，可以提交到第三方统计系统，当然也可以根据需要独立开发一套小型统计系统。

方案3是本人原创方案，方案的修改代码在以下附件中： 异步session统计信息同步，欢迎大家使用。

由于dz的开发考虑的是大众市场，功能冗余代码逻辑复杂。但优化dz并不是那么的困难，而优化的思路，也是跟其他系统优化相似：mysql瓶颈。一个即将崩溃的系统，或者频繁崩溃的系统，是进行优化的最好示例：减少sql查询，提高sql语句查询效率。dz考虑大众市场，为了提高产品兼容性，并没有引入太多的第三方软件：比如memcached，bdb，ttserver等，虽然内部已经为主从预留了接口，但未见很明显的文档支持。
第三个方案优化的思路也很明显，减少sessions表的慢查询而改为memcached高速的数据存储，把统计功能做接口留出，此功能给第三方来做。这样sessions表的瓶颈即可消除。

今天一天没干别的，没写程序，没玩游戏，除了中午参加公司的一个吹气球比赛得了第一，获得“**公司第一吹”的称号。

一天都在考虑使用完全开源的方案来解决dz sessions表的性能问题。中午大脑极度紧张，以至于撞在关兄的工位，工位几近散架。

在轻度震荡中想到一个优化方案，就是分离sessions表的一些功能，把sessions会话和统计功能分离，并且统计使用异步提交。

这样，如果sessions会话生存期10分钟的量计算，20万人同时在线，sessions会话存memcached，而统计只用少量字段在独立的表中。因为php的sessions操作速度高，而统计信息调用并不是非常频繁，并且查找也是简单的int型查询，速度快，并且也进行memcached缓存。

下午吴同学详细讲述了我们的统计系统的负载和数据量，在大量实际应用的基础上，我的方案应该能很好的实施。

这样算来，连接瓶颈跟存储瓶颈似乎都能解决。明天集中时间实现这个方案。

最近一直在寻找一个开源的方案来解决discuz的性能瓶颈。在做完几个关键表的分表后，sessions表又成了最大的瓶颈。因为页面每次刷新，至少两个sql语句在session表上，究其原因，session表的最大作用在于对用户行为的统计。

曾经尝试过使用php的session，不过支持phpsession的几个sever都不支持条件查询，除非是遍历匹配。这样也不能起到提高性能的作用。

在以上条件下，我寻找了两套方案：ttserver mongodb。

在session表100w数据的测试下，得出以下数据：

连接测试-只测试连接释放
tt:40.0904033184
mysqldb:0.0669066905975

mongodb:226.840053558
mysqldb:0.154407262802

经过一万次的连接测试，同一个脚本中，
ttserver连接耗时 40.09 秒，而mysql连接耗时0.07秒 linux下测试
mongodb 连接耗时 226.8 秒，而mysql连接耗时0.15秒 linux下测试

但是在500次的查询测试中，同一个脚本中，主键查询和索引优化后的复杂查询
mongodb 查询耗时 0.021 秒
mysql 查询耗时 0.123 秒

可以看出，tt和mongo两个功能上完全支持此表优化的数据库，在连接性能上远不如mysql，而web为频繁连接中断的服务，显然并不适合做这项功能。

继续寻找支持此功能的开源方案，欢迎大家提供线索。

用户中心代码 sso
跨域测试脚本 cookie

单点登录，英语为 Single Sign-On，粗俗点讲，就是登录一次，全站适用。

单点登录在应用中的实际意义，就是减少开发量，增强用户体验。

减少开发量，指的是：只要开发一套用户系统， 各个系统统一调用。用户系统尽量优化接口，通用性，安全性，达到一次开发， 全站适用。

增强用户体验，指的是：用户一次登录，全站登录。而不是切换一个模块，就登录一次。

web方面单点登录主要是用cookie传递令牌进行身份认证。简单说下令牌。

我这里用散列值来作为令牌，当然散列值之中有我的的密钥，防止别人伪造我的令牌。

环境：sso.sunboyu.cn 用户中心 vps.sunboyu.cn/cookie.php 跨子域不同脚本访问测试。 令牌密钥: $key

具体规则： sso.sunboyu.cn 用户登录，登录信息写到cookie，cookie做用域为 sunboyu.cn。并且生成令牌sso_key=md5(uid+username+key)。

登陆后，其他子域站点调用此cookie信息，并且验证此令牌是否是合法的令牌，if( md5( cookie[uid]+cookie[username] )==cookie[key] )

这样既可判断，此令牌合法性而确认此用户为登录。

具体demo:http://sso.sunboyu.cn

延伸：一个简单的md5似乎很容易让别人猜解加密的算法，来暴力一翻也不是没有可能，因此，除了加密外，算法的安全性和密钥的安全性也是需要考虑的。

如果安全级别要求高之又高，可以考虑rsa算法，不过速度就是问题了。其中又参考了一些朋友的意见，用对称加密，比如php中的Mcrypt 函数。

扩展开发：对于大多数网站，跨子域的单点登录就能满足应用。但对于一些域名复杂的网站，比如sohu，显然多个域名不能用此方法实现。这时就得搞出跨跨的单点登录系统。等年后继续得瑟。

前两天还不知道啥是无模式数据库，不过最近迫切需要修改discuz bbs的session表，所以研究了一下相关的资料，发现了无模式这个名字。

具体无模式是啥，这里找了两篇文章：

关系数据库的末日是否已经来临
关系数据库的根本问题分析及数据库革命之走向

关于无模式的应用案例，很典型的一个，就是康盛uchome的feed表。

这里简单介绍几个无模式数据库，供大家参考：

mongodb : http://www.mongodb.org/display/DOCS/Home

mongodb的php扩展 http://www.mongodb.org/display/DOCS/Installing+the+PHP+Driver#InstallingthePHPDriver-PECL

这个数据库已经在淘宝上配合10gen做了云计算的session（名字很操蛋）,具体资料在这里 http://rdc.taobao.com/blog/dw/archives/410。具有了实际应用的东西应该很不错，不过我没尝试过。

Tokyo Tyrant：http://1978th.net/

tt的php扩展 http://www.php.net/manual/en/book.tokyo-tyrant.php

这个大家就比较熟悉了，SB日本鬼子写的东西，应用很广，sina，qq等公司里都在大量应用，sina的研发团队在此基础上还做了个分布式的东东，很是不错。据说这玩意还得到了很多公司的赞助，shit。

TCSQL：张宴基于tt开发的一套东西，内部做了很多算法优化，具体可参考此文章 http://blog.s135.com/tcsql/

总结：康盛使用mysql来存储session，不能说是一种错，但对于dz的负载绝对是第一个瓶颈。用这种方式，在线人数5w对数据库绝对是个坎。很多负载比较大的论坛，都做了此方面的优化，比如，给session表单独一个数据库，或者干脆阉割此功能。不错，独立的session表，或者分库，访问量大的时候，瓶颈依然在mysql上；阉割此功能，有些心疼，而且很多运营数据会丢失。所以，保持原功能而平滑提升性能，是一个不错的解决方向。

很多操作时间会很长，不能让用户在页面上执行PHP脚本，否则页面会被拖死。

一个不错的方案，就是提交到后台去执行。

linux有个命令 nohup command & 这样就会提交到后台，而终端的用户体会不到程序执行的过程。

原来我使用这种方式 shell_exec( “nohuo php file.php &” ) 进行后台提交，后来发现速度依然不快， 还是被挂起了。查看手册，exec函数有如下提示：

Note: 如果用本函数启动一个程序并希望保持在后台运行，必须确保该程序的输出被重定向到一个文件或者其它输出流去，否则 PHP 会在程序执行结束前挂起。

因此，这样修改就达到了目的：

exec( “nohuo php file.php >> /dev/null &” )

最近一直在琢磨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优化好，其实是个不错的产品。

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

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

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

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

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

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

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

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

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