一个程序猿

终于完成了Tokyo Cabinet的jsp接口，在tomcat下性能不是那么出众，看来性能还是得用c。

部署方法看上一偏配置说明。

代码 api.tar.gz

信息插入与修改：

查询：

http://192.168.138.29:8080/search.jsp?database=sunboyudata2&query=fid:QCNUMEQ:1604&skip=20000&max=10

database:数据库文件名[无扩展名]
query:查询条件 每组查询条件三个部分 字段:规则:值 每组之间用|分割
skip:记录起始
max:返回的记录条数

缺点：在频繁大数据量提交的时候，tomcat总是影响失败。性能没有预期那么好，tc需要优化。

二维码是什么？

看这里：百度百科：二维码

二维码我用的最多的就是利用android手机的二维码扫描功能扫描网址，当然这种方法还大量应用在货物标签，比如我们去超市结账的条码扫描。

二维码利用近距离的光线进行数据传输，打破了网络数据线的依赖，可以说是一种打破常规的非常方便的应用。尤其在各种设备并不那么兼容的情况下，用二维码交换少量信息是非常便利的。

二维码的算法是通用的，二维码PHP的生成，我发现了以下几种方式：
1、某日本作者写的PHP http://www.swetake.com/qr/qr_cgi.html
2、开源社区上的PHP程序 http://phpqrcode.sourceforge.net/
3、google提供的一个接口 http://code.google.com/intl/zh-CN/apis/chart/

这里我尝试了第二种方法：下载软件包后，使用里边的方法：QRcode::png

我写了个代码是这样：

require_once(APP_PATH.'/include/phpqrcode/qrlib.php');
QRcode::png("http://www.sunboyu.cn");

这样就可以输出二维码图形了，可以用手机尝试一下。

通过观察，大部分的dz论坛在数据量发展到一定程度，在线人数逐渐提高后，首先锁表的是sessions，这个表我已经写过多种优化的方式，不外乎寻找一些比mysql负载性能好的程序来代替这部分工作。但时间长了，随着在线人数继续增加，那个附加的程序也会面临瓶颈。提高硬件性能和软件性能固然能提高负载，但一旦到瓶颈，必须想其他的方案。

硬件和简约的程序能提高性能，在大数据量下，算法的优势就能体现出来了。

顺便提一下主从：很多人认为主从可以解决问题，其实未必。设想一主多从结构，假如主库写压力很大，那同样压力会同步到从库，会造成N个从库压力同时很大。事实上从库压力会小于主库，因为主库是多进程写，而从库是单进程写， 但总的来说，执行的语句不会少。所以，主从这种结构在一定情况下也就失去了优势。（在硬件资源充裕，压力不是很大的环境下，这种问题发生较少，在硬件条件比较差的一些环境下，这种瓶颈很容易表现出来）

这里拿discuz7的posts表举例，摆脱主从结构，硬件比较差，表很大，10G以上。

一个负载大的dz论坛，在线人数多，又比较活跃，那posts表的压力肯定不会小。在一个回复比较频繁，存储引擎使用myisam的posts表，锁表是经常发生的，我所遇见的问题发生的环境为：数据库单点，无主从，io压力中等。posts表频繁锁表，而造成查询排队，查询速度骤然下降。

在不提升硬件的情况下，要想提速，显然是比较困难的，大量的文本数据装入memcached显然也不合适。所以，这个问题我用优化数据存储的角度对数据表进行了改造。

TIPS：同样100M带宽的集线器和交换机，交换机的吞吐性能远远高于集线器，原因在于：交换机建立专有通道，避免了冲突。

而在mysql中，锁表可以形象描述为冲突了，读写冲突了。但如果我们分表，把读写分散，也许会好点。

分表规则：按照tid进行hash，分散到16个表中。

假设，一读一写，两个操作，同时进行，那么他们撞在一起的几率就是1。如果分为两个表，那么他们撞在一起的几率就是1/2 = 0.5,用一个函数来表示，就是F(x)=1/x ，显然，分的表越多，冲突的机会越小，锁表的几率就越少。即时锁表，影响的也只是1/x的数据，不会对所有的用户造成影响。

数据模型解释：如果是绝对同步发生，几率应该是 F(x)=1/((x-1)*x)，但在计算机里，无论两个操作时间间隔多小，在cpu时间片上都是顺序执行，因为，函数我认定为：F(x)=1/x。

以上用数学的方式解释了算法优化对性能的提升。实际上，通过对逍遥论坛的用户行为统计：posts表95%以上的操作都是在读写，搜索和管理占小部分。

补充一种分表算法：在discuzX里，后台启用了分表，我没有细看，大概是把表按照时间段或者其他条件分开。我猜测，作者本意是拆分老数据，主表只留最新数据和一些命中高的数据。这种方式可以起到一定效果，但根据统计，大部分用户习惯浏览回复最新帖子，因此，大部分的读写还是定位到了一张表，也就是没有彻底解决读写冲突的问题。
还有一个朋友使用的是顺序分表，500w个pid一张表，但这个方法同上个方法，没解决冲突问题。
所以，在他的基础上，我考虑出按照tid进行hash分表的方案。

说到这里，分表又给我们带来了麻烦，有些查询并不能用tid主键进行定位，这里我用了mysql合并表，这个合并表可以合并16个分表，成为一个大表进行查询，而表名依然用原始的表明，这样，dz中原来的功能就不受影响了。

此方案已经实现，我用的新老数据+分别hash的方式，即32张表存储posts数据的方式。但未做压力测试。最近努力学习loadrunner使用，这个压测马上就可以进行了。

已经全部调试通过，正在往一个线上环境上部署。文档也在敢写之中，谢谢关注。

自从09年10月份接到公司论坛改造升级任务到现在，逍遥论坛 http://bbs.xoyo.com 在性能和负载方面相对稳定,修改了原来的结构，单程序可以支持多论坛(模仿5d6d http://www.5dforum.com/ )。有几个参数可以参考：

平时在线人数：5000~10000人 峰值：50000+（超过5w后，统计表性能明显下降，关闭了统计）

之前每逢峰值论坛常挂，改造之后有充足的预案防止出问题，保证论坛用户能及时在论坛传达必要消息。

在论坛改造过程中，我写了很多文章来表述改造中的一些心得，也认识了很多朋友一起讨论dz的优化。其中最宝贵的经验，是一些无能为力的站长把他们的服务器交给我，让我亲手在一个大负载的服务器上去做优化，在这个过程中学到了很多系统优化方面的知识，更宝贵的是获得了大负载下dz的一些瓶颈点的数据。

由于考虑用户群的问题，很多技术没有办法用开源的软件实现，也无法找到替代品，考虑实际，很多dz站长自己并没有实力去涉入维护一个更改很多的论坛，所以我的方案并没有大量去应用。

在帮朋友优化的过程中，提到更多的是技术实力与维护、需求的增删与性能的平衡。

所以，我得出这样的结论供大家参考：

1、每个功能都会吃系统资源，充分考虑每个功能是否必须，不必须的功能一定要砍。

2、找系统压力点：根据我对逍遥论坛用户日志的分析，90%的压力集中在 forumdisplay.php viewthread.php上，而这些脚本的压力主要体现在表联查而造成的锁表上，最主要的表就是sessions表。sessions表集合了很多用户统计相关功能，因为，优化此表，结合上条原则，合理增删功能，达到压力减小。

3、硬件的优化。硬件优化也是我最近考虑的一个方案，想对于开发人员，硬件的开销还是很小的。合理升级硬件也是一个不错的方案。

以上结论是针对中小型网站已经碰到瓶颈的dz程序做出的建议。

而对于一个负载很大，并且有实力的团队，那在discuz上要做的文章就太多了。

1、拆表是必然的，而对于一些数据量不大但经常变动的表，完全可以全cache。

2、根据需求删改功能。discuz很强大， 但不是每个功能都是你必须使用的。

3、开源产品会给你很多灵感。

推荐的一些开源技术方案：

memcached(不用说了)

Tokyo Cabinet DBM:性能极佳的持久存储的keyvalue数据库

mysql udf http http://blog.s135.com/mysql-udf-http/ 让tt变成从库？

lucene 必须要替换discuz默认的搜索

你还有什么想法？

一时兴起，写此文。欢迎有兴趣的朋友加 discuz性能优化讨论群 qq:41886598

研究PHP设计模式其实很久，不过真正在使用上却用的不是很多。但凡设计模式都用在大型负载的商业软件商，而对于web开发，尤其一些短平快的产品，设计模式显得不是那么重要。而只有一些非常核心和通用的部分，我们加以封装，主要是方便复用。

通过最近做一些项目，松散的设计明显不能满足项目的需求，随意的代码虽然能加快项目进度，但也造成很严重的技术透支。

重新认识框架，可以得出以下体会：

框架的确是限制人的，但不是技术的限制，不是思想的限制，而是规范合作的限制。

项目的设计规划人员要付出更多，其设计了框架的核心后，开发人员在你的思路下进行开发，你的一点点错误会在几个人身上得到成倍的放大。

坚持一种设计思路，即使已经走了很多弯路，但起码保证这些弯路要走踏实，而不是一条泥泞的弯路。

一个优化的框架不仅是完成基本功能，更要让开发人员感觉爽，这是最重要的（很难实现）。

最后，继续琢磨我的框架吧。

—————————-题外话——————————–

最新学了一段时间的C，包括我以前也提倡，用写C的态度来写PHP。写C语言，每个变量，每块内存都要完全规划在你的脑子里，处理不好，程序是绝对跑不动的。做PHP项目，也要注意这些细节，虽然PHP是弱类型的语言。当然，做一个项目，也要去考虑方方面面。

http://blog.csdn.net/alexdream/archive/2008/03/24/2213344.aspx

http://devzone.zend.com/node/view/id/1022

http://blog.csdn.net/alin0725/archive/2007/04/08/1556460.aspx

http://devzone.zend.com/article/1024-Extension-Writing-Part-III-Resources 这篇文章不错，讲PHP如果管理连接符

http://www.phpbbchina.com/wiki/index.php/%E7%BC%96%E5%86%99PHP%E6%89%A9%E5%B1%95 中文教程

在我搞完公司的论坛优化后，我一直想写一个圈套的dz性能优化的方案。当时的全文检索使用的是公司内部某人开发的检索系统，没有开源，所以我做此方案来实现。
此文刚打完草稿，处于调试通过的状态。没有形成具体可用的用户文档。希望在这个底稿的基础上，朋友能给予测试和支持，以鼓励我做出一套完整的方案。

下载：lucene_dz

欢迎加入QQ讨论群：41886598

最近论坛发生了一些问题，某用户A登录后变成了某用户B。此事在某阶段频繁发生。在排除了账号服务器的问题、程序自身问题后，在网上又发现类似现象：
淘宝账号诡异事件：
http://diybbs.it168.com/viewthread.php?tid=593134&extra=&page=1

我点到我自己的淘宝里面，进入了一个陌生女子的界面
不过这个bug只出现了一次
这个人我已经加上了，是个卖魔方的

卡巴斯基中文官网论坛账号诡异事件：
http://bbs.kaspersky.com.cn/viewthread.php?tid=15891

有登录论坛出现别人信息的会员请进这个问题，论坛上已经有不少会员碰到。管理员正在设法解决这个问题。凡是出现这种情况的，请在下面回帖，向管理员详细说明以下情况，帮助管理员更快解决问题
1、出现问题的频率和条件
2、进入论坛的方式（例如是收藏夹进入、直接输入网址进入……）
3、论坛登录名和密码的保存方式（每次输入，不保存；按照多少时间保存）
4、有无别人和你共用电脑
5、使用的浏览器，及其版本
6、有无采取清除缓存文件，清除Cookies的措施，效果如何？
7、除以上措施外，有没有采取过其他措施，效果如何？

GMAIL账号诡异事件：
http://www.gseeker.com/50226711/aecceaecgmaileaeieie_139265.php

看到这个标题，你可能会认为这是天方夜谭。但事实上，这是完全有可能发生的。某天，你在登录Gmail时，尽管你100%正确地输入了自己的用户名及密码，但出现在你眼前的却是别人的Gmail邮箱。如果你第一时间怀疑自己的眼睛，那你就冤枉它了。因为至少在科威特，部分Gmail用户本周就经历了这样的怪事。

通过这些事件的观察，和对一些论坛账号发生错误的账户主人的询问，基本确定了以下几个可能点：

1、缓存的错误。因为discuz使用cookie进行身份认证，而一些代理缓存了cookie头，造成一个cache多人使用造成的问题。http://bbs.chinaunix.net/viewthread.php?tid=837214

2、依然是缓存的问题。只不过这个缓存可以存在于cn大局域网，或者某些ISP，比如google的例子，或者某些地区的服务商，抑或……

您是通过什么网络上的淘宝，据我所知，移动的浙江固网宽带出现过类似的严重安全隐患。宽带网络运营商的问题很大（强制建立缓存代理服务器，缓存不该缓存的网页），网站的问题是其次的。或者说，在那种情况下，绝大多数网站用户都会出现“穿越”现象。
如果被你穿越的人和你斗处在同一城市，基本上就是这个原因了。

解决方法，且听下次分解。

如果您的网站出现类似问题，欢迎加我qq176300676一起收集数据样本进行分析

亦可加入msn讨论群 lampper@live.cn

最近一直在折腾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表的瓶颈即可消除。