作者文章: Fenng

财帮子(caibangzi.com)网站架构

财帮子(caibangzi.com) 定位在”基金理财社区”。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的,且不去管,不可否认的是,目前国内”理财”是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)Meng Yan ( 孟岩 ) ,还有一位”不写Blog的家伙”。前两位都是技术人员。很早就看过孟岩 的 Blog,那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的,所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师,叫赵路,曾经是 Mozilla 项目accessibility模块的module peer.”

2.服务器信息

Web 服务器用的是 Lighttpd ,出于节省成本的目的,服务器是自行组装的。数据库采用的是 MySQL 5,目前还没有使用 Replication. 正准备扩充服务器,服务器数量…暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit,”以及自己写的一些分析 Proc 的脚本”,再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇 财帮子性能优化简报披露:“财帮子两个星期以前,遇到严重的性能问题,最终我们采用了相当非主流的部署方案和打了自己补丁的web server,成功度过了难关”,我很好奇这具体是个什么问题。得到的答案是:“Apache的负载均衡是有问题的,算法太简单了,对Ror的应用来说,会造成某一个app instance的阻塞,从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器, 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache,到disk的cache,
再到数据库的cache,架构还不错,否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好,也是Cache没用好
Meng Yan: 是啊,Cache非常重要,非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽,命中率非常之高
Meng Yan: 确实,我们的内存cache就是用的memcached,真的很棒

5.挑战

这是就这次采访的最后一个问题。

Fenng:还要采访你一个问题:caibangzi.com 现在运营、开发面临的最大的一个问题是什么? 
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线,到现在已经积累了一定数量的用户,当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是,不要太在乎站点流量,流量本身也是开销),网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构,我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息,相对来说,国内站点还是比较保守,各自闷头折腾。为什么不换个角度,分享、借鉴、壮大,这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料,联系我!(要写软文就免了)。

EOF

烂片有烂片的看法

每个周六,如果没有事情出去的话基本要在电脑上做两件事情,一是看看《南方周末》等报纸杂志的电子版,二是看看最近 BT 来的一些电影。

今天很有幸,又看了一部烂片子《葬礼揸Fit人》(《龙头葬礼》)。港产电影的剧本似乎可以好几家共用的,这个《葬礼》和最近的那部《兄弟》大情节有很多相似之处。导演也不说考虑一下大陆观众,“揸Fit人”这词谁懂啊?查了半天才知道大致是“话事人”、“总瓢把子”的意思。演员莫名的神经兮兮,情节也莫名的不合常理。看港产片子容易产生审美疲劳,翻来覆去就是那几个演员,本片居然看到了好几个还不那么熟悉的面孔,扮演兄弟的那个貌似林志颖,表演那不是一般的生硬,下次建议导演来大陆招几个演员算了。

说烂片有烂片的看法,主要是里面的一些场景和台词挺有意思。来参加葬礼的世界各地老大,无论哪个人怎么看都不像个老大的样子,倒好象来香港的游客跑了个龙套。那个帮会是”红“字头的,那个兄弟,叫做“家宝”,帮会老大去世后,下面的兄弟们准备”选举“;四个老头子自持资格老,开始底气很足,没过一会儿就临阵倒戈,这些似曾相识的情节会让人联想许多。记得的台词有:”一个人是斗不过社团的,社团斗不过政府,政府最大”。

接下来看疑似烂片的《神枪手与智多星》,第一句记得的有趣台词是:

时代进步了,黑社会不能再存在了
--帮会老大校长深沉的说

烂片的另一个作用是消磨时间

EOF

终极数据库恢复工具 AUL 升级:支持压缩表

国内数据库技术牛人, Oracle ACE Fangxin Lou 自行开发的 AUL 最近有了一次比较重要的升级:支持压缩表。有趣的是,据他自己说是经过了 20 分钟的发呆 想到的解决方法。很多人都知道 Oracle 的 DUL(Data Unloader) 是数据恢复的最后一招,一般来说是密不可宣的,一旦给用户恢复数据则代价昂贵,而 AUL 则平民化了许多,虽然不是开源的,但是国内用户如果使用的话,基本还是不收费用的(功能还毫不逊色)。

Lou 最近也作了一次 AUL/MyDUL发展历史回顾, 这个工具都三岁了。难得的是坚持,这一点我很服气他。

关于 AUL 更多信息可以参考他为推广 AUL 而做的 英文 Blog
EOF
BTW: 鲜果上我的BLOG验证代码: BANG1F1D675F0C335CE77C173BA6XIANGUO

eBay 的数据层扩展经验

对于 eBay ,我盲人摸象一样写了好几篇 Blog ,暂列一下:

今天又重新读了一下这篇《The eBay Architecture –Striking a balance between site stablility, feature velocity, performance, and cost》,觉得数据层的扩展经验也很有意思。

通过功能划分不同数据库,然后根据主要访问路径水平分割数据库。这句话太空了,类似 MySQL DB 大家常采用的 Shard 思路。

减小 DB 资源开销

数据库上没有业务逻辑。这包括:不用存储过程; 只有少量比较简单的触发器。
把CPU 开销比较高的工作迁移到应用上。这包扩:参考完整性检查(嗯,检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。

最小化 DB 事务

自动提交(Commit)大多数主要的数据库写操作。
客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于”事务”, 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键,这也是因为 eBay 的商业逻辑天然性质(否则也不容易做),所以可以做到 Scale Out,而最近了解到 Paypal 则因为交易逻辑比较复杂,只能是 Scale Up. Paypal 的技术信息一向比较封闭,谁能告诉我一点额外的信息呢?

EOF