不知道原因。推介个percona的工具 pt-query-digest

就这么丢着好了，实际环境中这种无效的图片比例很小。删除图片获得的好处（一点点的硬盘空间）远远比不上给系统增加的复杂性。

`for line in self.union_items_new_fd.readlines():`是一次读取全部的行吧。

`for line in self.union_items_new_fd:`

刚帮人做了个类似的站。 [email protected]

我猜走的是TCP连接，有TCP协议保证的吧

lvm里面有一个硬盘损坏会导致整个lvm卷损坏。

我们之前的图片就是用两级hash目录存储，当一块硬盘满了以后，基本就没什么好办法扩展。增加硬盘，然后软连接这个方法只能解燃眉之急。光拷贝就要好长时间，而且如果之后空间又满了，还得重复这个过程。并且单机能加的硬盘数就那么点，总会吃不消的。

如果确实容量可能会涨到一定的程度，那还是直接搭一个分布式存储的方案比较好。如果都是小文件的话，可以看下豆瓣的beansdb。如果是大文件，且io不高，看下moosefs。（直接套用豆瓣的架构）

@alex321 b 关注了 a 的情形下，a 的其他操作事件也将触发系统对 b 的提醒。

这个应该算关注动态了。虽然也算广义上的提醒，但具体实现时和第一种情形分离应该比较简单。

is_empty(val) - - ， 直接 bool(val) 就好了么

@dagger 如果整存整取，不用对某个字段进行查询的话，并且 NOSQL 的场景不多，直接在 MySQL 里面塞 JSON 吧，另外单独架一个 NOSQL 运维成本太高了。

@alex321 notification 用 message queue 来做会不会杀鸡用牛刀了。消息队列这个东西太复杂，还得去维护消息队列这个设施的可靠性，丢消息的情况啥的。对一个小系统来说，相关的逻辑被拆分到了多个不同的系统中，维护会比较复杂吧。

我们的提醒的结构用的是 1 结构，实际在使用的时候发现提醒的类型数目有限，基本是可穷举的。这样在实际构造HTML代码的时候比较麻烦，但是逻辑上还是比较简单的。

desc notification:
id | sender_id | receiver_id | action | target_id | extra | create_time | delete_time

sender_id: 提醒的发起人
receiver_id: 提醒接收人
action: 什么动作触发的提醒
两部分组成，第一部分为行为的代号，第二部分为目标的代号
行为代号：
评论101， 关注102，新朋友103，赞104，做过105，@别人106, 回答(问题) 107, 提问 108, 官方消息109
目标代号：
菜谱1001， 用户1002， 讨论区话题1003，作品1005， 菜单1007, 问题1013
target_id: 触发提醒的动作的承受者
extra: 动作承受者的补充信息，默认为''
create_time: 提醒创建时间
delete_time: 提醒需要被删除的时间


delete_time表示提醒即将被删除的时间，当delete_time为NULL时，这是一条未读提醒。当delete_time为一个合法的时间时，这是一条已读提醒。到达delete_time时，此条提醒被移动到notification_r1表中，此后此条提醒对用户不可见。

用crontab定期根据delete_time来清理提醒。

@dagger RDBMS 塞json，会导致没办法按照字段索引

@sedgwickz @hanes 这几个链接里面的效果是需要手动用手指去控制方向，网易那个只需要调整iPhone的朝向，视角会自动改变，不需要用手指操作

@est @garipan 在iPhone 或者 iPad上面看，移动设备的时候，视角会自动跟着变化。

@fityme
@refresh
@jasontse 感谢，不过不知道这是个bug还是新浪API就是允许这么调用的？

@strak47 我只登录了新浪微博，没有授权他的网站。

pip install uwsgi
好像会默认安装 uwsgi-plugin-python

豆瓣的 beansdb

新写一个function作为celery_task，里面调用 类成员方法

我也遇到这个问题