本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/10/qclub-ruby-on-rails/

周日(2008-10-19)下午，去听了听QClub组织的Ruby网站架构案例分享──财帮子&FreeWheel，本意是冲着架构案例分享去的，对Ruby On Rails知之甚少，很久以前和BLUG的一位外国朋友聊天，他说是做Ruby的，我说Ruby是日本人开发的语言，还没等我说完，这位外国的朋友说：It’s just a language,nothin to do with Japanese，其实我的本意是这是日本人开发的语言，国际化方面可能会差一些，比如最原始的文档应该是日文的吧。看来我们总是被人误会啊。

首先是财帮子的Robin Lu(陆亦斌)给我们分享了一下他们的建站经历，先介绍一下财帮子的基本情况：

• 财帮子目前大概是100万PV/天，注册用户大概十几万
• 人均访问PV大概在15～20个左右
• 网站访问的峰值大约在基金净值出来之后，最高大概是430 Rec/Sec
• 最开始只有一台1U的服务器，应用和数据库都在上面，现在两台1U的服务器，应用服务一台，数据库一台
• 系统构建在Ruby On Rails上
• 使用lighttpd做负载均衡，30个左右mongrel实例
• 使用Munin和monit做服务器监控，跑了一些的cron任务(如数据备份)

他们遇到的第一个问题是前端负载均衡效率不高，最开始用apache的mod_proxy_balancer，发现有阻塞的情况存在，现在用的是lighttpd做负载均衡，他们觉得效果不错，据说还毙掉了nginx的方案，由于久做PHP，印象中前端负载均衡应该是把请求均衡到多台服务器上，初一听他们的负载均衡是把请求均衡到多个实例上，觉得甚是费解，一打听才知道mongrel一次大概只能处理一个请求，不太了解，不好评论。

他们的第二个问题是发现Ruby On Rails里面的数据库操作有大的瓶颈，大概是对数据库的操作始终在一个事务中，不到最后不commit，所以导致死锁的情况屡有发生。这让我想起Rasmus Lerdorf老大对PHP Framework的批判Simple is Hard(用IE会被鄙视的)，Framework大大提高了开发的效率，却捆住了我们的双手。如果想要高的效率，那么就让ORM见鬼去吧。

他们还有一个好的建议是把动态内容和静态文件分开处理（当然这个建议已经被无数人说过了），这个确实非常有必要。

听完报告，问了下财帮子目前的瓶颈在什么地方，答曰：内存缺乏，跑了30个mongrel直接就吃掉了2G多的内存，确实够凶猛。这方面PHP算是不错了。

另外报告中还提到他们每天需要2～3小时去处理用户的账单，比如基金净值出来了，然后他们会计算每个用户的账单情况，这种做法不太看好，想想现在十几万用户可以算出来，将来多了呢？多台服务器并行计算？可计算成本呢？提前计算网站的活跃用户足够了，那些几百年才来一次的用户或者注册了再也不上的用户大可不必，等他们访问的时候再实时计算吧。

后面分享的FreeWheel讲的大多是项目开发方面的经验，我倒是觉得FreeWheel的做法不错，各种Framewok适合快速开发网站，不见得适合开发快速的网站。

感谢财帮子和FreeWheel的分享，技术其实就那么点事，还是开放一点好。

对Ruby On Rails实在了解甚少，上述内容如有不到之处，请不吝赐教。