这样的排版方式简直是自爆流量。
我觉得在网页上面做一下优化，比如 30 个图片一个分页，这样至少大家不会一个首页就占几十兆的下载流量一直挂着。压力太大你 10 个图片一个分页也可以，现在的速度，用户看那么大一片表情等半天没有意义。
其次就是语义化图片，辛苦一点，录入图片的时候稍微根据图片内容起个有含义的标签或者标题，方便做展示，同时加强一下 seo 的效果。

redis 做起来更方便， lpub/lsub 都是原子操作。
业务逻辑实现起来更简单，代码量也少。

mysql 一定要做，可以考虑这样的操作：
update task set status='process' where status='pending' limit 1;
只要并发不是很恐怖，这个操作可以当成是原子操作，只有符合 status='pending'的才会被更新，拿到成功更新的状态就说明成功取到任务，然后取具体的数据进行处理。

我最近在思考的，因为想要试着总结一个快速理解其它语言做 web 开发的思路，整理了一下做 web 开发可能会涉及到几个模块的东西。
如果这些功能都可以自己用代码实现一遍，应该就可以完成一个简单的 web 框架了。退而求其次就是能够看懂实现这些功能的代码，那也应该可以改一个 web 框架了，再次一点就是能够看懂这些功能的接口文档，那也足够用一个 web 框架开发了。

route
路由 url 到对应类或文件的机制
global
全局变量，用于保存运行中必须的公共参数，例如数据库连接参数和状态，各种 web 系统配置参数
evernt driver
事件驱动模型，用于根据请求处理的状态调度任务。常见于非阻塞 web 框架。
hook
处理请求生命周期的过程自动调用的唤醒处理函数，例如请求处理前、请求完成后
signal
通知消息，用于在处理某个业务的时候发出消息和参数，由接收方决定如何处理消息。
import/call
引入通用函数，或调用某个子类函数
session/cookie
用于缓存用户态数据，做客户端数据隔离和权限审查。 session 可选择内存数据库或文件形式读写， cookie 需要了解 set_cookie/get_cookie 的操作和 http 编码
header
http 请求处理的协议头，读写 header 字段，可能会用来传递公共参数， restfull 的 web 服务会用到。
upload/file
接收用户上传文件，需要处理文件类型，保存文件路径等内存数据与文件系统的交互
get/post/put/delete
http 几种请求形式，接收不同请求形式的参数和数据。
template
渲染返回页面模板，用于将不同参数渲染到模板中返回给浏览器
parse
解析各种正则匹配规则，用于提取数据
message queue
消息队列机制，用于处理系统内异步处理的业务消息通知，需要完成收发消息、存储、调用指定函数功能，基于 signal 、 import/call 完成的功能
extent
扩展，安装其它扩展功能或者其它应用的协议扩展。
connect to other server
连接其它服务，例如借助 extent 扩展协议支持，连接 mysql 、 memcache 、 mongodb 、 redis 等独立应用开放的服务。
task pool
任务进程管理池，用于创建连接池便于加强与外部请求的通信效率，常见有数据库连接池，或者配合 message queue 实现的任务管理池。
httpclient/TCPClient/UDPClient
发送 http 请求所需功能,通常集成 curl 向外部 http 服务发送请求的处理，或者通过其它扩展与其它服务器进行 tcp/udp 协议的通信。
convert image
用于解析或生成图片数据。常用于生成验证码、打水印等基础图片处理功能。

熟练工种是需要工作量锤炼的，再怎么样忙，分配任务之前可以先给时间让他做一下设计，然后问清楚设计思路，有问题在设计思路审核的时候就可以给他点拨。
如果他有问题，就提供足够的资料让他自己思考方案，实在解决不了就点拨一下思路。
再不行还是想不出来方案，就告诉他具体的实现思路，让他写代码实现。
如果还理解不了实现思路，也写不出来代码，那给点补基础的书籍和学习路线，让他学几天看看领悟力。
如果确实书都看不进去，辞退了让他回去好好补基础。

这个情况一个是他没有遇到问题就问的习惯，另一个也是没有提供足够的指点和交付时间节点的约束规范。
到时间交付这个要敲打一下，但是他遇到的问题还是得给他解决，问清楚思路都有什么疑难解决不了，提醒他遇到问题一定要马上联系上级做反馈，不要自己把问题捂着。

A*并不能保证最优解算出最短路径，它的评估函数是为了尽可能选取可能最优解优先进行深度搜索。设计 A*算法的目的是用错误率换时间和空间，不寻找最优解的情况下，尽快计算出一个可行解。
如果你一定要计算最短路径， A*算法并不适合。

既然你已经用矩阵表示无向图了，那么两点之间的距离是无法估算的，你能做的只有靠起点到目前节点的权值总和做估值函数，预设一个估算权值，即如果已经连接的节点权值越小就优秀扩展此节点进行搜索，超出估算权值越多优先级越低。恶劣情况就是退化成广度搜索，如果估值权值选得算法好，还是有可能剪枝成功实现快速出解的。

tornado 内置的 httpclient 吧支持异步，单进程 qps 可以到一百多，多开几个进程就可以了。
不好的是不能限制并发数。

一般的压测工具读取一个构造好的 URL 列表，顺序读完去并发执行，很多工具都支持读取构造的 URL 列表。

犯罪手段的话，看看能不能求到几个黑服务器的黑进去，整套代码加上部署方案一起拖走，再去挖几个熟悉代码的开发人员看看。

认真说的话，先交个几万块咨询费帮你梳理需求，需求整理稿和执行计划的方案费用另计。

@yeqiu
是的就是这两点。
任何社区都会出现意见领袖，至少在用户时间轴上少了 xxx 赞同了 xxx 问题下的 xxx 回答。
我还记得这个点赞操作的动态推送到时间轴的时候知乎有过讨论和抱怨，用户关注别人的本意是看他的回答，而不是看他的赞同，加上这个功能之后，整个推送变成了以人的操作为中心，通过用户操作实现了跨话题的信息流，由用户对回答的点赞操作进行协同过滤，避免了低质量的问题推送给用户，做出这个改动之后知乎的信息流就变成热门回答合集了。

知乎只要时间轴恢复最开始以话题和问题为中心，就没有这些大 V 的公关业务了。
现在的问题根源是时间轴的推送以关注用户为中心，这就导致了一个关注数量巨大的大 V 进行操作可以带来巨大的传播度，好处非常多，至少水化的问题和回答不会污染大部分用户的时间轴。坏处就这个意见领袖问题。

恢复以问题和话题为中心，只推送话题和问题下的新增内容和改动动态，那么就只会存在某个话题或问题内的大 V ，用户群的时间轴被各个话题割裂成一个个孤岛，可能会形成不同的用户群体，意见领袖只能在某些话题下耕耘回答才能够积攒起影响力，换一个话题则很难将影响力迁移获取，至少我的关注都会回到新问题和新回答上。坏处就很多了，垃圾信息太多，至少在早期我还会点开所有问题去翻最新的问题和回答，现在根本不敢去看，太多无质量的问题和回答，很难从所有问题里面找到有质量的问题和回答，水化垃圾信息太泛滥。

知乎所谓的实验性功能宣称会根据用户关注话题和问题的动态操作进行推送，实际上就是以人为主，新的问题和回答很难推到用户时间轴上。首页能看到的永远是热门内容。

我知道大部分用户很懒，不愿意学习早期知乎推崇的各种礼仪，知乎在新人门槛上也放松了约束，用回答发表评论和吐槽内容都成了常态，逗机灵回答几乎个个问题都有，这个不做新人静默期的社区礼仪教育，很难扭转氛围。

我喜欢逛的另一个 Python 开发的社区 hupu 也开始引进板块考试制度，要想在板块发言必须要回答一份问卷，通过了才认可用户的回复操作，如果知乎有一天内容质量下降到很差的程度的话，我希望知乎也能引进类似的制度提高回答和点赞的门槛。

就不能保证转正这个事情，很难招哦，毕竟要半年，这实习时间换个其它公司有转正名额的，更安心一点吧。
毕竟六个月时间只有大四的能挤出来，到时候不保证，总不能让人临毕业再找工作。

增加一个 ID 字段建索引，然后维护一个时间节点和 ID 的映射表，可以考虑按小时或者分钟建，就是大于等于时间 xxxxxx 的 ID=1100 。
这样可以根据时间段取出范围的两个 ID ，之后快速根据 ID 取出一个时间段。
性能肯定比时间比较好，但是查询硬是拆成两个，等于分表了。

死海效应，公司管理制度留不住高质量的人才，也招不进来高质量的人才，最后留在公司的都是能力不强的人上去做了管理层，进而失去竞争力，最后死掉。

你可以看看丁香园，在医学的学术交流上它是聚集最多医疗领域用户的。

Google analytics 统计没有被墙，墙的是管理后台，统计业务可以正常使用

Google analytics 不试一试？
百万 PV 单服务器是没有问题的。这点量对于服务器配置而言还是绰绰有余的。

对复杂问题的抽象，如果解决方案精巧简洁，那就是很牛的程序员。
比如那个 quake 里面的快速计算开方函数。

代码书写风格和备注的风格是好习惯，应该是工程化方面的指标，可以说明程序员在工程方面的协作和开发效率很高。

偷懒的时候直接写个接口专门扫文件，然后输出注释就显示，这样给前端一个 Web 接口就可以看所有注释了。
好处是只需要维护一份文档，方便实时更新，把注释写好就行，坏处太多列不完，文档不规范，没有格式等等一堆工程化要求没有达到