新建任务后，存到任务记录表里面，标记状态为 0 。
调用 django-crontab ，每一分钟扫描一下未执行的记录。
如果发现当前时间和设置的时间一致，则执行，并更新任务状态。

最坑爹的是群聊里面的语言消息，。。。

IIS 没啥问题啊，挺稳定，挺好的。

@shoaly 哈哈，我也就是上来吐槽下。等 2 天而已嘛！
大家说的压缩，实际情况是，目前服务器只有不到 20G 的空间。而且目前的数据其实已经有比较高的压缩率了，就算压缩其实也没有多大的下降空间了。所以就干脆直接传了。

@Aliencn 等会研究下 oss 看看着么弄！

@ic2y 已经压缩过了！

国企有倒闭的可能，倒闭了就是下岗潮。
按照 LZ 的描述，企业的效益不行，而且管理乱七八糟。说明企业处于僵尸状态，回头国家政策改变了，不给僵尸企业输血就只能等着被下岗了。

1 ：关于是否需要拆分，需要确认的是， django 在做数据查询时， ORM 是否会把所有数据都带出来（也就是 Select * 和 Selece 特定字段的区别）。还有一个情况就是字段的存储的大小，如果都是小字段，其实没有太大的拆分必要。如果存储的字段都是大字段，我觉得还是有拆分的必要的。
2 ：建议还是用 OneToOne 的方式吧，这样可以保持一个数据库结构的完整性
3 ：其他问题，暂时未知。

ps ：如果 LZ 不准备做水平拆分，目前只考虑垂直拆分。只需要从存储的字段大小以及 ORM 的性能上来考虑。如有不正确的地方，请斧正。

转发到 QQ 邮箱，用 QQ 信箱收件。速度妥妥的

我也觉得应该是幸存者偏差。。。

一般都是 token+用户名，在数据库中查询 token 对应的用户名。
如果用户名和客户端发送的一致则继续正常的访问。
如果不一致丢 401 错误。

之前做了好多年的小说站，小说站的小说详细页面都是存的金泰文件。总结下
优势：
1 ：系统的压力都在 IO 上， cpu 几乎无压力。对 CC 攻击天然免疫
2 ： cpu 的压力释放出来了， cpu 可以干一些其他的事情，比如说采集

劣势：
1 ：系统迁移是灾难
2 ：对于硬盘是很大的挑战，如果服务器丢在云上还好一点。但是服务器如果在物理机上，那硬盘如果换掉了，那就刺激了。
3 ：如果前期页面没有做好，在页面上加入广告，或者加入其他代码那就是灾难
4 ：如果管理程序效率不高，页面重新发布也是灾难

2.7 还是继续用 2 年再说，到最后一年再考虑换 3

@crashX 这属于非常非常小概率事件，基本上不会发生。就算发生了，主键是唯一的，也保存不了。

@liuzhen 这样处理我觉得主键索引的效率会下降吧。。。。

就当做一次数据迁移吧，查了一下资料也没有找到很简便的处理方式。
LZ 看来这体力活是躲不过去了。
如果有好的方式，请分享下。

文档，需求讨论， TODO 都在 basecamp
代码管理在 bitbucket