用分布式代码版本控制在服务器挂掉的时候可以不阻塞工作，只本地提交。

我只懂得穷举

看好go

@9hills 取决于里面有没有实质内容

卖盒饭或者早餐

真治不是中二而是缩卵～～LOGO用得不对～

@fengluo 关系数据库把太多责任赋予了数据库，熟悉关系数据库的人经常会用SQL的思维写出很苦涩的逻辑。该让数据库还原它“储存”的基本职责了。

@reus 哟，这个屌

@lychee 单单用数据库也能做，很多时候会用表单模拟另外一个东西。类似where().desc()的查询就是每次重复生成一个队列。

最近在做一个订阅列表，一开始想省事用mongodb储存，后来发现mongodb对列表的支持只能从列表尾部插入，而且不能限制列表长度，如果在应用层中实现想要的效果（比如一个timeline）会费很大劲，于是就加上redis了。

当然做着做着，发现部署的门槛是高了。不过我想就算stackoverflow开源，也不如让人们直接泡在他的网站上好。

@xiaovfight 我意思是豆瓣流行的“尼马”之类的词语是会减分的。然后你的链接中最有价值的是github帐号。PS：iteye链接要去掉/admin路径

补充，上面提的status也是从内存取的，只有内存里没有才从数据库取，然后存到内存缓存

然后系统的后端实际是各类id的队列和以id为key的对象缓存，加上3%的数据库读操作。

@lychee 现在SNS应用的解决方案就是：内存。

比如一条status，引用了topic,reply,user,replier……而且这些数据是不定的，那么关系型数据库是查询不了的。

用关系型和非关系型的解决方案都是把行数据放到内存里。status单独取出来，status.topic, status.reply, status.user, status.replier都是从内存里取。

其实“队列”另一个角度看就是“索引”

该从豆瓣毕业了

我好像过早进入技术细节了。

一切皆有可能

用mongodb解决文档的多变模式
用redis维护feed类队列
稍微放松数据的一致性，解放思维

XD 做出来给你看……

群组可不要，关注必须有，这是现阶段的心得。有了关注，就有了feed。各方面可以参考下github的watch

@fanzeyi stackoverflow是基于.net写的，db是sql server http://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/

最近看见了好些python优越症小孩

奥，我想投资我自己，但是我不想花钱

感觉你们的界面看得出你们艺术热情四散，但是还不会“收”——让用户关注重要的地方