一个程序猿

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

一天都在考虑使用完全开源的方案来解决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为频繁连接中断的服务，显然并不适合做这项功能。

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

editplus默认是不支持python开发的，但官方提供了相关的支持：

http://www.editplus.com/dn.cgi?python3.zip

在 菜单->工具选择->语法 中，可以新建语法类型 python,扩展名 py,语法文件为python.stx,自动完成文件为python.acp

即可。

以前用apache，很多虚拟主机的时候，用 mod_vhost_alias 模块去解决。nginx似乎没有这样的功能。

原来为了做这个功能，我用python写了一堆脚本，去自动管理nginx的配置文件，结果还是不理想。频繁重写配置文件，频繁重启，总会出现点问题。

在nginx的0.8.*下，发现了这样的功能：http://wiki.nginx.org/NginxHttpCoreModule

Since nginx 0.8.25 named captures can be used in server_name:
server {
server_name ~^(www\.)?(?.+)$;
location / {
root /sites/$domain;
}
}

大喜，于是乎做出如下配置，实现了nginx下自动虚拟主机的功能：

测试通过。

我的开源虚拟主机管理系统nginx版本指日可待。

新浪微博，就是迷你博客（废话）。我关心的不是博客，是url。里边的url全部使用了一种很短的url，比如 http://sinaurl.cn/**** 这里猜测了这种url的实现意义：

1：减少url所占的字数，优化排版。微博就是一个小，如果我贴了一个地址就占一半的字数，那作者很不爽，读者很不爽，做页面那哥们(MM)肯定跟不爽。所以，咱弄个短的url，岂不皆大欢喜。

2：排挤灌水广告者。众所周知，很多广告者为了广告，或者为了页面优化，得群发垃圾消息增加反向链接数。而短url跳转这种方式根本无法增加反向链接数。也就是这种方式从根本上掐断了垃圾群发者的命根子，这样也就减少了垃圾信息的量，节约了信息审核的人工成本（这项成本随着严打是越来越高啊）。

3：暂时没想出来。

实现，其实很简单，就是接收个id，然后找到对应记录就行。根据新浪信息的量，不可能用mysql的，成本高（负载和硬件消耗）。不可能用oracle，凭我的了解，不可能用。

新浪在小日本那个ttserver的基础上开发了个支持分布式的key->value型的数据库，这玩意正好用上，支持高并发大负载，逻辑简单还支持分布式，这么实现貌似最好不过。

吃饱没事，大半夜写文章。欢迎大家来讨论。

用户中心代码 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 &” )

自打上篇文章 康盛，这么做是不是有点过火了发表后，引起很多朋友讨论。有些朋友从技术上抨击了这种做法，有些朋友从商业上去理解这种做法。当然，我们是搞技术的，单纯从程序安全和数据安全上来分析一下。

老样子，后台有个get提交：
http://u.discuz.net/customer/update.php?get=a%3A16%3A%7Bs%3A7%3A%22sitekey%22%3Bs%3A16%3A%22f270e28a8b0Qv1Y8%22%3Bs%3A7%3A%22version%22%3Bs%3A3%3A%222.0%22%3Bs%3A7%3A%22release%22%3Bs%3A8%3A%2220090825%22%3Bs%3A3%3A%22php%22%3Bs%3A5%3A%225.2.6%22%3Bs%3A5%3A%22mysql%22%3Bs%3A6%3A%225.0.22%22%3Bs%3A6%3A%22dbsize%22%3Bi%3A1298163%3Bs%3A7%3A%22charset%22%3Bs%3A5%3A%22utf-8%22%3Bs%3A8%3A%22sitename%22%3Bs%3A12%3A%22%E6%88%91%E7%9A%84%E7%A9%BA%E9%97%B4%22%3Bs%3A7%3A%22feednum%22%3Bs%3A2%3A%2210%22%3Bs%3A7%3A%22blognum%22%3Bs%3A1%3A%220%22%3Bs%3A8%3A%22albumnum%22%3Bs%3A1%3A%220%22%3Bs%3A9%3A%22threadnum%22%3Bs%3A1%3A%220%22%3Bs%3A8%3A%22sharenum%22%3Bs%3A1%3A%220%22%3Bs%3A10%3A%22commentnum%22%3Bs%3A1%3A%220%22%3Bs%3A8%3A%22myappnum%22%3Bs%3A1%3A%224%22%3Bs%3A8%3A%22spacenum%22%3Bs%3A1%3A%223%22%3B%7D&h=aa380aa3

urldecode并且反序列化，得出这么一堆东西

sitekey是什么？通过阅读代码，sitekey是pre_config表里一个字段，跟以下代码配合工作

它跟manyou服务器配合，才有权从你的服务器上拉取你数据库中的某些信息。

其他字段，我们看字面意思基本也能知道是干啥用的。

继续运行程序，我们看当一个用户第一次安装应用的时候做了什么。

这个信息要从服务器上截取，我是根据nginx日志和程序中截取反馈信息获得的。

服务器日志：

manyou服务器发来post请求。post信息不会在日志里，底下是我抓取来的信息：

做过sns网站应用开发的应该很容易看懂底大概是什么意思。
看看我们的程序给manyou平台返回了什么信息：

有了这些数据，我又注册了一个号码，把资料填全，看看是不是都被抓走：

差不多基本资料都过去了。

这样，可以看出，康盛的服务器不断得在抓取用户的信息。这个事情是不是过火，从商业的角度，是应该很过火的。他把用户产品内的账号信息等关键东西都抓走，这些信息到他们手里，难免会交易给竞争对手。
但是，从技术上讲，康盛的manyou服务器还有个缓存的功能。如果拉取用户信息这个请求都放在网站的服务器上，我相信大多数虚拟主机的用户会不堪重负，而康盛其实为这些负载买单了。买单的结果，就是你得把用户的信息提供给康盛。就这么简单。

从程序安全上讲，你的数据库信息，尤其用户信息，在你的网站和manyou之间共享，而康盛没有拉走用户或者管理员资料，也没有发现其他信息的提取，所以，两者之间是安全的。第三方网站是无法获得这些资料的。

但从商业安全上讲，康盛的服务器是否可信？康盛是否会拿这些信息作一些站长不希望做的事情？这个只能由官方来解释了。

睡一觉，研究其他产品去。

感谢铎哥的配置，感谢宴哥解决ssl连接的问题。