有需要，受欢迎。

楼上正解。

道高一尺，魔高一丈。

复杂一点的，可以分析用户鼠标、键盘等动作。

验证码简单的话，可以试试机器学习搞。图省事儿的话，用打码平台。

@haikea 那贴点错误提示看看？

应该说『看来果然空穴来风啊』。

#我就是歪楼的，不用理我，你们继续。

可以。前提是你的 C 代码里没有使用系统调用相关的函数。

『李敖认为，所谓“丑陋的中国人”只是一种刻板印象而已，柏杨将一部份中国人的丑陋加诸于所有中国人之上，是懦夫的行为；』

喜加一

台湾李弘毅老师的课程：

http://speech.ee.ntu.edu.tw/~tlkagk/courses.html

可惜没人给你批改作业。

还是吴恩达老师的 Coursera 课程更好一些，在线测试、编程作业，能让你理解得更深入。

V2 还有个 fast.v2ex.com 。。。
我一直用的是 www.v2ex.com

按文中的链接算了一下分，我竟然能得 165 分。

话说，好几年前关注移民的时候，不知从哪看到了新西兰这个度假签，感觉挺有意思，就胡乱填了一下不知道干什么的表格。后来就时不时给我发邮件。

因为最终办了加拿大的移民，所以就没再关注这个新西兰的度假签了。

听说有人正在推动英联邦四国签证。如果真成了，那四个国家随便跑，岂不是爽歪歪？

厉害了我的工作室

@Icezers 那是最终的问题哈。

一开始如果连并发都没解决的话，前面一分钟只能接一万个请求，那『 UploadToS3 速率过慢』又从何而来呢？
前面九个馒头不吃的话，怎么直接吃第十个馒头呢？

没仔细看代码，从描述来看，感觉作者及同事处理问题的步骤没啥大问题。
但估计是作者没有真正理解每个环节所遇到的问题的本质，所以给人有种『吃了第十个馒头饱了，就觉得前九个馒头都没用』的感觉。

简单梳理一下：

1. 最开始他们遇到的问题是『要处理来自数百万终端的 POST 请求』。

这其实是要解决并发数和响应时间的问题，顺带要考虑突发流量问题，即要『削峰』。

这时候他们采用协程去解决，没啥问题。
（有简单的解决方法，肯定用简单的哈。）

2. 解决了并发数和响应时间问题后，导致了爆协程的问题。

请求确实不少，协程处理没那么快的话，当然爆掉了。
尤其是遇到突发流量的话，服务不死才怪。

为了解决爆协程的问题（注意：这个阶段的问题已经和 1 中的问题不是同一个问题了），
那就用队列吧。至少队列可以控制数量哈。

这时候他们解决问题的方式，也没啥可指摘的。

3. 这时候横着爆的问题变成了纵向爆了。

用队列代替协程之后，协程数量爆的问题变成了队列长度爆的问题。

这个阶段才把吞吐率的问题暴露出来。
无论横着竖着都爆，那就是说明问题是数据处理不够快哈。
那开个线程池，多放几个线程处理数据呗。

这时候他们的解决方法，也没得说。


最后，既然每一步都没啥问题，但整个过程为啥给人一种有问题的感觉？
我认为，唯一的问题是整个团队没有有经验的人。
有经验的人，遇到这种情况的时候，至少能把各个阶段面临的问题理解清楚，处理起来有的放矢。
更好点的，可以预见后续会遇到的问题，从而从一开始就采用不同的解决方案。
再好点的，可以迅速做出解决方案原型，并进行多项性能测试，从而采用最简单的方案把问题解决。
如果原型+测试表明，用协程就可以解决了，那直接协程就好了，队列线程池什么的就属于过渡设计了；
类似文中这种情况，原型+测试的方法可以极大地减少对生产环境的影响，
也尽量避免了开发人员为了紧急应对线上问题而疲于奔命。

工作九年，情况和楼主差不多。
但是马上就要换个环境从头开始了。