2年开发的rails网站及体会

我开发的网站是http://ichiba.cc
我是从rails2开始用它开发网站的。当时的想法是，自己比较宅，很喜欢日本nicovideo.jp的动画，里面的动画可以发送弹幕，很有意思。后来就想开发一个。然后得到nico的视频让更多的国人可以观看。由于是个人爱好，就选择开发效率很高的rails作为平台。网站最开始就是rails+thin+nginx，后来由于慢慢有了一部分和我一样的爱好者，我又开发了图片评论功能。但是觉得这种方式依然没有满足我对在线交流的渴望，于是开始研究消息服务器，观看了很多消息服务器的代码，发现很多消息服务器是基于消息复制的模型设计的，这样的处理非常消耗资源，于是和一个朋友开始开发代号“猫耳开关”的消息服务。这个时候国内的verycd被阉割。虽然是意料中的事情，不过这样的分享网站没有ed2k的资源了实在可惜。这时候很多爱好者抓取了verycd的很多资源作备份。我觉得这种方式非常不可靠，首先ed2k的种子有很多失效了。其次这种方式需要很多人贡献种子。于是开始想有没有什么方法可以自动生成实时的ed2k资源的种子。经过学p2p网络协议和ruby相关的库，我开发了在线实时搜索关键字生成ed2k的种子的功能，在我网站搜索栏选择kad进行搜索即可。不过虽然经过不断改进，搜索一次kad需要大约30秒。看来全球在线用p2p的人可想而知有多少。
最开始网站用的数据库是sqlite，因为当时是自己用，感觉维护方便。不过后来随着各种爬虫和用户的登录。sqlite经常发生lock.果然这种在写的时候锁定自己的数据库不能在web上大规模使用。然后迁移数据到了postgresql9.同时用nginx+passenger。这个时候又出现了新的问题。网站由于消息服务上线，经常发生莫名其妙的阻塞，然后网站就挂了自己百思不得其解。后来翻了无数文档。在博客园的一个大牛写了一个文章关于多线程fork的问题我才恍然大悟。passenger虽然部署很方便，但是他的开发模型是有先天缺陷的。主要在进程方面的处理上。如果一个网站只有rails一个服务，那么passenger还是可以胜任。但是我网站有一个ruby脚本从nico导入视频，一个脚本去作后台来实现消息服务器。这时候passenger就非常容易导致堵塞问题。于是网站换为nginx+unicorn。unicorn是pre-fork设计的，而且自己可以在链接一段指定时间内没有反应自动杀死。感觉现在如果在维护，性能上考虑部署rails，非常建议使用nginx+unicorn的方案。目前长连接上有人测试得到的结果是unicorn比passsenger快了10倍。虽然我没有那么大的感受，不过稳定性上unicorn现在做的确实非常出色。

rails的发展让我一路感觉到它的生命力和技术理念的先进。每一次升级都为了完美而割舍那些不需要的不合理的部分，而不是去最求那100%的兼容性，虽然我也吃过升级时候各种库的更新导致的一系列问题的亏，不过后来想想，这样长久来看，对rails的发展非常有力。现在ruby是1.92版本。听说ruby2.00开始在解决伪进程相关的问题，速度还要提升。自己非常期待。

更新历程：
　　2010.3，向国内一些ACG网站（ACG为英文Animation、Comic、Game的缩写，是动画、漫画、游戏（通常指电玩游戏或GalGame）的总称。）提出一些比较明显的 bug的改进意见无果以后，开始开发ichiba V1，实现了弹幕视频（flash实现 ）。
　　2010.9, 网站实现自动索引日本nico的动漫视频，通过一些技术处理让国内用户可以无须翻#墙就可以观看nico的视频并且下载VIP的视频。这时候网站后台全面升级系统完成ichiba V2，从rails2升级到rails3，sqlite更换为postgresql，以及日文中文的视频分词检索等等。
　　2011.8 网站开始试图从技术上和体验上超越国外同类网站，提供更好的功能体验。美化了前端，做出图片评论弹幕功能（国内ACG网站唯一提供此功能），实现了基于p2p的在线ed2k资源搜索（这个国内应该也是唯一提供这个服务），开发了中国ACG的首个消息服务器(代号“猫耳开关”)来方便用户的在线交流。


特点：1.自动索引日本nico的ACG视频提供中国用户播放，在播放器中发射弹幕。
2.可以上传图片并在图片上贴弹幕。
3.可以实时检索到P2P网络中用户关键字对应的ed2k文件，提供用户下载。
4.类似twitter的在线交流。

PS：nico是全球目前唯一实现盈利的视频网站，主要是因为它首创的视频弹幕功能，目前nico在日本，台湾，德国等设立了分公司。