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

嗯，确实牛。

我会这么干：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。