免责声明:这个答案完全与编程无关。但是，它确实试图从一开始就攻击使用脚本的原因。

另一个想法是，如果你的销售数量确实有限，为什么不改变先到先得的方法呢?当然，除非炒作是你营销计划的一部分。

还有很多其他的选择，我相信其他人也能想到一些不同的选择:

an ordering queue (pre-order system) - Some scripts might still end up at the front of the queue, but it's probably faster to just manually enter the info. a raffle system (everyone who tries to order one is entered into the system) - This way the people with the scripts have just the same chances as those without. a rush priority queue - If there is truly a high perceived value, people may be willing to pay more. Implement an ordering queue, but allow people to pay more to be placed higher in the queue. auction (credit goes to David Schmitt for this one, comments are my own) - People can still use scripts to snipe in at the last minute, but not only does it change the pricing structure, people are expecting to be fighting it out with others. You can also do things to restrict the number of bids in a given time period, make people phone in ahead of time for an authorization code, etc.

我们目前正在使用F5的最新一代BigIP负载均衡器来实现这一点。BigIP具有先进的流量管理功能，可以根据频率和使用模式识别抓取者和机器人，甚至可以从单个IP后面的一组源中识别。然后，它可以限制这些内容，为它们提供替代内容，或者简单地用标题或cookie标记它们，以便您可以在应用程序代码中识别它们。

My approach would be to focus on non-technological solutions (otherwise you're entering an arms race you'll lose, or at least spend a great deal of time and money on). I'd focus on the billing/shipment parts - you can find bots by either finding multiple deliveries to same address or by multiple charges to a single payment method. You can even do this across items over several weeks, so if a user got a previous item (by responding really really fast) he may be assigned some sort of "handicap" this time around.

这也会有一个副作用(我认为是有益的，但从营销角度来看，我可能是错误的)，可能会扩大幸运的人的圈子，购买woot。

这个问题的解决方案可能是在登录和购买操作中附加一些客户端处理。处理量可以忽略不计，因此个人不会受到影响，但多次尝试执行任务的机器人将受到额外工作负载的阻碍。

处理过程可以是一个用javascript解决的简单方程，除非你不想在你的网站上需要javascript。

问:你如何阻止脚本写手在一秒钟内上百次地攻击你的网站? A:你不需要。外部代理无法阻止这种行为。

你可以使用大量的技术来分析传入的请求，并尝试启发式地确定谁是人，谁不是人……但它会失败。最终，即使不是马上。

唯一可行的长期解决方案是改变游戏，使网站不再对机器人友好，或者减少对编剧的吸引力。

你是怎么做到的?那是另一个问题了!: -)

...

好吧，上面已经给出了一些选项(并拒绝了)。我对你的网站不是很熟悉，只看过一次，但由于人们可以阅读图像中的文本，而机器人无法轻松做到这一点，所以将公告更改为图像。不是验证码，只是一个图像-

generate the image (cached of course) when the page is requested keep the image source name the same, so that doesn't give the game away most of the time the image will have ordinary text in it, and be aligned to appear to be part of the inline HTML page when the game is 'on', the image changes to the announcement text the announcement text reveals a url and/or code that must be manually entered to acquire the prize. CAPTCHA the code if you like, but that's probably not necessary. for additional security, the code can be a one-time token generated specifically for the request/IP/agent, so that repeated requests generate different codes. Or you can pre-generate a bunch of random codes (a one-time pad) if on-demand generation is too taxing.

运行真实的人对这个问题的响应的时间试验，并忽略('哎呀，发生错误，对不起!请再试一次’)的反应比一半的时间要快。此事件还应该触发警报，提醒开发者至少有一个机器人已经弄清楚了代码/游戏，所以是时候修改代码/游戏了。

继续定期地改变游戏，即使没有机器人触发它，这只是在浪费编剧的时间。最终，编剧会厌倦这款游戏，去别的地方……我们希望;-)

最后一个建议:当你的主页收到请求时，把它放到一个队列中，然后在一个单独的进程中按顺序响应请求(你可能不得不入侵/扩展web服务器来做到这一点，但这可能是值得的)。如果来自同一IP/代理的另一个请求进入，而第一个请求在队列中，忽略它。这将自动减轻机器人的负载。

编辑:另一种选择，除了使用图像，是使用javascript来填写购买/不购买的文本;机器人很少解释javascript，所以他们不会看到它

目标的一个可能的解决方案，不一定是问题的标题:

Instead of serving up the special deal to everyone, serve it to random sets of ip addresses at a time. For instance, partition the IP space into 256 unique blocks, and at time=0, only allow people with ip addresses in the first block, and at time=5 seconds, allow people from the first block and the second block... until the last time slot arrives, and allow everyone to see the deal. One idea to randomize it would be to take the least significant bits of the md5/sha of their IP plus some salt based on the deal.

这将允许脚本编写人员拥有接近于零的响应时间，以及拥有多个ip地址的优势，但这将意味着给定的机器人与其他因ip地址而比他们“幸运”的客户相比没有任何优势。

将这一点与其他一些想法结合起来似乎是个好主意。