急啊，做一个5000并发的抽奖小网站，什么方案最佳

既然你们每次只做相当于一个页面的功能，那么就要看你们有什么基础了。如果你有腾讯的基础，就按照腾讯的做法做。你应该先把你们的基础搞明白，说清楚。基础不同，那么说了也是白说，根本就不能用得上。
-------------------------------------------------------------------------------------------------------
给你贴一下我在其它论坛回复的关于秒杀的一段文字：传统的电商下订单操作本身往往需要一个“很长的业务链”，而且后台需要访问相对一致的数据库系统。所以就算是有许多接入服务器，那么算法本身、以及访问数据库方面，也会成为瓶颈。对后台业务操作的异步化流程改造是最为核心的技术，因为只有这样你才打开了自由之门。传统的操作，程序员觉得比较简单好理解的操作往往是同步的。例如用户下单时，程序员可能以为要将数据库相关的改变全都改变完成，甚至将从一个库存调入另一个库存的转移成本都给计算好了，再给用户界面反馈结果。而进行改造之后，应该在“一瞬间”先反馈结果，而与用户界面没有直接关系的操作全都异步执行。 进一步，这些异步执行的东西，要求能够分布式服务器集群来执行。这样就可以随时水平扩展服务器。 返回头来，秒杀商品应该单品编码。秒到、秒不到某商品就是去执行一个“FindOneAndRemove”原子操作。而各个秒杀线程不需要进行“本次秒杀还剩下有多少商品可以秒杀”的协同（加锁）查询。 给秒杀用户界面进行反馈的一瞬间，异步地，把秒杀商品（单品）放入用户的购物车中，然后用户就可以使用普通的购物网页去支付。 客户端的秒杀程序是一个javascript富客户端程序，它虽然在购物页面上，但是可以自动负载均衡地查找反应最快的秒杀服务器地址，而不是访问商品浏览网页所用的服务器。这样，对那些浏览器商品的用户没有任何影响。  如果进行这个FindOneAndRemove原子操作达不到每秒1万次的速度，那么可以把秒杀商品编码数据放到单独一个服务器的“内存数组”中（查到一个商品编码之后就将数组单元的值修改为0值），这个服务器仅仅对其它服务器提供一个单独的FindOneAndRemove原子服务。由于此数据和操作与系统中其它数据库、其它服务完全分开，对其它系统的影响很小，可以让迟早会失败的排队者尽早失败。  这里的功能点：1. 商品的单品管理流程。 2. 异步多线程操作。  3. 分布式任务调度系统。   4. 将顶层业务数据放入拆分的SOA中。