一个程序猿

没想到这两个词具体是什么意思，但这肯定是我的缺陷了。

前几天培训，被指出这个毛病，其实仔细回想，工作中何尝不是没有头绪条理，很多事情忙的团团转，搞的一团糟。

改正这个毛病其实用了很长时间，从期初开始做简单的文件记录，到后来大量的纸质手稿，到现在详细的记录和思维软件(mindmanage)的应用，对做事有了很多提高。

昨天晚上加班，自愿加班，去完成一个我所认为半天就能完成的工作，其实用了将近一天，实际工作时间也算半天吧。时间浪费了一大半，是因为以前已经实现的一个冗杂的逻辑又去想了一遍，结果还没想明白。后把之前的逻辑拿来，20分钟顺利结束了战斗。

非常勤恳的工作不是啥好事，漂亮得完成工作并把时间留给自己才是王道。

前段时间，我的网站自觉和谐了，留下了一个空荡荡的服务器。当然，有个必须解决的事情，就是月付的租用费用。

我挣的都是辛苦钱，更让我明白了时间就是金钱的概念。因此，我得让我的服务器有所产出。

想了很多种方案，有好友提示：学习芭比豆淘小宝之类的网站，出租相册空间给卖家也不错。伟大！

遂开始配服务写代码。写到一半，突然发现，时间付出也许跟此项目的产出严重不符。一台服务器利润太小，除非实现规模化运营。而我最不擅长的就是销售，看着写了一半的程序心疼，遂产生念头，把代码开放给需要的人，作为一个开源项目让其自生自灭。

我知道程序员为啥都穷的叮当了。

演示：http://taobao.sunboyu.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表的瓶颈即可消除。

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

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

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

我是剑三里一小商人，小本生意下自然不会有太多极品的材料，不过小生意也红红火火。做生意自然要关注市场动态，底下谈谈朝廷和金融的一些动态。

最近朝廷发威，70个区服封杀外挂将近2500多个。兴奋之余，不免悲哀：我的唯一的一个古井泉由三天前的1700金将到了1200金，世界频道很多人以千金的价格抛售，难得一个冤大头1050金买走了我的古井泉。

古井泉价格下滑，跟封挂有着密切关系。封挂，意味着大量的古井将回归到玩家手里，更有小道消息：古井的爆率大部分将放到副本里。综合这两个因素，外挂商大量抛售古井套现，而玩家也有了获得古井新的手段，价格自然会回降。

朝廷用金融的手段来封外挂，比技术手段高明得多。

再谈封挂对其他物价的影响。

受古井降价影响，很多玩家开始筹备铸造或者缝纫高级紫装，古井泉到位，其他材料自然要凑齐。千年冰芯、珍珠缀放的价格有所上涨，是三天前的5~10倍。其他普通材料变化不大，但有上涨的趋势。

由于很多外挂被封，绫罗水波零这些普通的日常冲级材料会涨价。以前交易行的低价材料大部分都是外挂商打出，他们的倾销造成价格很低。

中冷泉五莲泉由于广阔的市场，价格依然坚挺，隐月线、天山雪水等蓝色材料，根据爆率和市场需求，价格会保持稳定，不会有太大起伏。

最近铜锭等低级的材料又涨价趋势，因为很多70级的铸造材料，中间需要铜锭等。因此，小号们赶紧多打点铜锭，技能练习采矿铸造，又能小发一笔补贴家用。

剑三的市场跟真实的世界有很大的相似之处，因此想发财，还是要多关注我们的财经报道。谢谢各位大侠。

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型的数据库，这玩意正好用上，支持高并发大负载，逻辑简单还支持分布式，这么实现貌似最好不过。

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