问题描述
近几年，各大电商甚至各个运营商，都经常搞一些秒杀活动、抢红包等。比如某月的11号10点，某品牌手机“1元秒杀”，限量100部。此时，必然在10点前后，网站的并发量会相当大。为了应对网站的高并发，我们可以使用应用服务器集群，负载均衡器会将请求分发到各个应用服务器，这样各个应用服务器的流量就会小很多。但由于集群时同一个应用部署在多个应用服务器上，此时，对于这个100部的限量，该如何保证不会卖多呢？单节点的时候，我们可以在应用内部使用锁和计数器来保证，可以使用类似于JDK内部的CountDownLatch这些并发组件，我们可以在应用内部使用锁和计数器来保证，但在集群环境下，这个应用内的计数器就没有意义了。应用被分发到各个服务器，此时为了保证这个数据的正常，一般常用的手段有哪些呢？比如我们可以让所有的Server访问同一个数据库，这样来限制，但此时数据库就会成为瓶颈。为了解决瓶颈问题而采用数据库集群的话，各个数据库之间如何保证数据的同步的呢？另外，如果使用Redis等分布式缓存，这样的话，为了解决单点问题也必然会有多个分布式缓存存在。此时多个缓存节点间的数据如何保证？没有从事过互联网应用的开发，不知道这类需求该怎么实现，请论坛内有相关经验的朋友指点。谢谢。 问题补充：@kidding87 和@greemranqq 回答的都很赞。由于我个人没有这方面的经验，有些你们提到的解决方案，像请求缓存，请求排队之类的，还是有些茫然。当然，这是和个人经验有关系。如果在指出实现方案上能再具体一点就更好了。
解决方案
1.秒杀活动，一般做得简单点，大家访问的都是同样的界面，页面全部进行缓存，秒杀按钮一般等到时间到了，才点亮，才生成URL，防止提前通过URL 访问。2.秒杀一般请求数特别多，在秒杀开始之前，URL 不开放，页面有缓存，无论用户怎么刷新，也不会给服务器造成压力。3.秒杀一旦开始，会有很多请求出现，但是一般我们只允许比如前100个有效请求，这个100个请求进行订单处理，其他请求都进入缓存好的，秒杀结束页面。4.实际上我们仅仅对有效请求进行处理，这里的处理办法可以对请求加入队列，当数目达到100，就不在添加，然后可以依次从队列里面提取信息，处理我们需要的结果，不会出现超标的情况。5.对于数据库的设计，一般情况下，如果量比较少，可以用专门的服务器来处理有效订单，其实请求就不会太多，压力不会太大了。6.在你分布式集群里面，假设你有N台服务器，那么你可以规定每台服务器仅仅处理100/N g个订单，同时你也可以做一个全局计数器，利用分布式缓存框架。7.因此你说的数据库压力，以及分布式数据同步的问题，可以得到很好的解决。关于分布式集群之间的通讯这些，可以靠消息中间件，或者延缓等等各种手段处理。 8.上面仅仅是个人想法， 提供一些参考，有问题请指出~。~
解决方案二：
不错。。。学习了。
解决方案三：
Memcachedredis在分步式计数效果很不错我们在秒杀之类的，基本都不让请求怎么过数据库1、设置请求本地缓存2、使用squid之类的请求缓存3、web的服务器做本地缓存+分布式的缓存4、MQ异步处理数据持久化