Rails 用 Rails 做 Instagram 的后台,要怎样架构?[内附连接]

bryanwong · 2012年04月20日 · 最后由 zeeler 回复于 2012年06月08日 · 6701 次阅读

Instagram 已经超过 4000万用户了,采用 django + CouchDB 开发,部署在AWS EC2平台上。

Instagram 一共只有 5 个攻城狮,其中两个还是最近加入的。

下面是一些链接:

Scaling Instagram http://www.slideshare.net/iammutex/scaling-instagram

Instagram 架构分析笔记 http://www.dbanotes.net/arch/instagram.html

大家能详细地谈一谈,如果采用 Rails (+ MongoDB),该如何架构 Instagram ?

(不用考虑是否【过度优化】的问题,我们只是探讨^_^)

共收到 13 条回复

我不知道,这个是一步一步来的,我认为保持良好的水平扩展性是必要的。

嗯,确实牛。

我会这么干:nginx + puma/unicorn + sinatra + memcached/redis 作为api层(多台server)环境,puma/unicorn + rails + redis + mysql/mongodb(一台server)作为管理后台环境;当然了,如果是这种业务,还要自己配置图片服务器。压力全在api层上,管理后台不要承担过大压力(数据库通过redis减压)。rails本身带的东西太多,内存消耗大,效率稍差,api层建议采用比较简单的框架,或者用rack自己写。目前单台api server可以承受每日1500万以上的调用,当然还可以继续优化。这里没考虑热备、灾难恢复等,负载均衡公司有硬件设备,所以也没在考虑之内。

#3楼 @zeeler 数据库通过redis减压 你们是怎么做的?

instagram重要的是后台,海量数据的存储、查询和水平扩展;对前台更多的是提供api,因此如果是我我也会放弃rails;即使要用ruby也会和 #3楼 一样,用更轻量级的框架。

至少从我看来,MongoDB 是首先排除掉的选择,你要考虑到 instagram 开始做的时候,即便是现在,我也更愿意选择 CouchDB,毕竟数据库还是要的,MongoDB的功能跟常见的RDBMS还是太接近了。CouchDB,在运行效率和开发效率上的平衡上做得更好。permanent views都会因为map reduce这样的写法,有很好的index。当你想做的事情确定了,你可以在浏览器里,用JavaScript写(有些东西用Erlang写不方便的话),把逻辑实现对了之后,再改用 Erlang 写一遍,这样就好了。水平扩展也有现成方案可以用。而在MongoDB里,为你的查询定制索引就没那么直接了。

参考 http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

2010年选Django也没啥好奇怪的。那时候,disqus那帮人在DjangoCon上做了个分享,介绍了他们scaling的经验,他们同时也在GitHub上分享了他们的一些补丁以及Django app。Disqus的应用类型和instagram也没相差太远。你可以在instagram的架构上找到一些disqus的痕迹的。2011年,Mozilla也分享了他们scaling的经验,还有代码。instagram也在2011年介绍了一下他们的经验。

相比 rails ...

参考 http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus http://blog.mozilla.org/webdev/2011/07/26/scaling-django-to-a-global-audience-with-playdoh/

#6楼 @bhuztez CouchDB? 现在貌似不怎么更新了吧,我看它的创始人都一直在弄CouchBase了

riak 偶在用介个做海量存储

#8楼 @ShiningRay CouchDB早就已经作为一个Apache基金会的项目存在,创始人离开并不会导致CouchDB开发突然停止,你可以在CouchDB的JIRA上看到,开发还是在继续的。

个人感觉CouchBase和CouchDB定位不一样,没自己动手试过CouchBase,这个可能只是我的偏见。

https://issues.apache.org/jira/browse/COUCHDB?report=com.atlassian.jira.plugin.system.project:roadmap-panel#selectedTab=com.atlassian.jira.plugin.system.project%3Asummary-panel

#10楼 @bhuztez 我用过couchbase(安装过)我觉得比较完善,比如管理界面方面,而且couchbase合并了membase(一种memcache服务),当然也具体没有测试过,看看谁有兴趣试试

如果直接用 Redis 做数据库呢? http://blog.sina.com.cn/s/blog_5374d6e30100tgwf.html

不知道 Ruby 有没有相应的实现?

#4楼 @kehao 数据库减压有多种方式,需要看具体需求;比如数据库中取出的内容列表,可以用memcached,对某个文章的好评(例如顶、踩)可以用redis等等,但是具体实现细节要考虑周全,比如cache过期后更新时的机制:如果一批用户同时访问时正好碰到cache要更新等情况需要自己特殊处理一下。

单独说redis减压数据库的话,主要是用redis来cache需要更新记录的内容,然后异步同步到数据库中,不要让前端压力直接压在数据库上。查询的cache建议用memcached。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册