笔试题:6000每秒秒杀系统设计

[anoxb]

一团购网站的笔试题。”秒杀“系统设计：秒杀数量有限，必须支持每秒6000人同时在线抢购，异步在线支付。
求教：怎么在6000人/秒的压力下，控制秒杀数量。
给个思路，感激不尽。

我自己的一些想法：
参考我们自己的生产环境，1台tomcat的连接数也就500这个量级，所以6K怎么也需要10台以上的集群。我们用nosql来做过计数，但没有这个大的并发要求，我们有一个类似的业务，用redis实现的，能达到900/s的链接数。
求高手给个思路，6000次/s的在线秒杀，怎么实现。

[星光一影]

• 静态化 o采用JS自动更新技术将动态页面转化为静态页面 • 并发控制，防秒杀器! o设置阀门，只放最前面的一部分人进入秒杀系统 • 简化流程 o 砍掉不重要的分支流程，如下单页面的所有数据库查询 o 以下单成功作为秒杀成功标志。支付流程只要在1天内完成即可。 • 前端优化 o采用YSLOW原则提升页面响应速度

[以专业开发人员为伍]

引用 80 楼 qq_16518805 的回复:

看你们个个都用后台缓存队列等技术解决，在下有个不是用技术的小妙招，根据理论我觉得可以支持任意次数的访问量 具体实现如下： 如果是6000/s 可以分配20台服务器 一台分300左右的负荷，那么如何有效的调度分配呢 既然后台服务器的负载有限那么 可以利用前端技术来实现 20台服务器分别对应不同的域名端口 通过前端页面的不同地址可以设置前端页面的随机地址来达到动态地址访问 随机数由前端产生 保证随机值在20台服务器之间 20台服务器分享同一秒杀缓存商品库 这样就可以有效的分配负荷 而不需要有一个强大的服务器来顶住压力 当然首先需要一个引流的首页，这个很简单

操作本身需要一个“很长的业务链”，而且后台需要访问相对一致的数据库系统。所以就算是省掉了反向代理服务器这么一台服务器，那么后台也是需要有一堆服务器并行处理业务。

[以专业开发人员为伍]

对后台业务操作的异步化流程改造是最为核心的技术。传统的操作，程序员觉得比较简单好理解的操作，往往是同步的。例如用户下单时，程序员可能以为要将数据库相关的改变全都改变完成，甚至将从一个库存调入另一个库存的转移成本都给计算好了，再给用户界面反馈结果。而进行改造之后，应该先反馈结果，而与用户界面没有直接关系的操作全都异步执行。 进一步，这些异步执行的东西，要求能够分布式执行。这样就可以随时水平扩展服务器。 返回头来，秒杀商品应该单品编码。秒到、秒不到某商品就是去执行一个“FindOneAndRemove”原子操作。而各个秒杀线程不需要进行“本次秒杀还剩下有多少商品可以秒杀”的协同（加锁）查询。 给秒杀用户界面进行反馈的一瞬间，异步地，把秒杀商品（单品）放入用户的购物车中，等待用户使用普通的购物网页去支付。 客户端的秒杀程序是一个javascript富客户端程序，它虽然在购物页面上，但是可以自动负载均衡地查找反应最快的秒杀服务器地址，而不是访问商品浏览网页所用的服务器。这样，对那些浏览器商品的用户没有任何影响。

[以专业开发人员为伍]

如果进行这个FindOneAndRemove原子操作达不到每秒1万次的速度，那么你可以把这个数据放到一个单独一个服务器的内存中，这个服务器仅仅对其它服务器提供一个单独的FindOneAndRemove原子服务。反正这个操作是瓶颈，而其它的操作都可以异步、分布式地执行。

[不落神话]

领教啦~

[潇潇雨云]

[MiceRice]

引用 86 楼 sp1234 的回复:

如果进行这个FindOneAndRemove原子操作达不到每秒1万次的速度，那么你可以把这个数据放到一个单独一个服务器的内存中，这个服务器仅仅对其它服务器提供一个单独的FindOneAndRemove原子服务。反正这个操作是瓶颈，而其它的操作都可以异步、分布式地执行。

说得挺好。如果进一步简化的话，可以只需要原子计数器做 Inc&Get，至于按序找到对应的单品这个应该是没并发问题的。 不过更有意思的讨论还是，如何能多台服务器来实现这个核心计算，尤其是还要再考虑下FailOver的情况，哈哈。

[slwsss]

学习

[_Nick_]

1.业务流程：页面使用静态+js+cdn 或者 动态页面+对象cache+cdn 2.订单队列系统：做必要参数验证，验证并减少库存，告诉调用者成功或者失败，然后直接入订单队列（异步队列） 3.订单系统：根据上一步队列结构，出队列，生成订单数据 4.库存系统：搭一套shared redis 系统， 在商品上架时把库存入到redis中， redis库存结构设计原则是已每个sku作为key分散到不同的redis中 5.支付队列系统：接受银行通知，入队列（可根据不同类别或者商品设计多个队列）（异步队列） 6.支付系统：根据上一步的队列结构，多线程出队列，处理订单状态，记录日志。

[jianwu5]

引用 3 楼 aalansehaiyang52 的回复:

tomcat是应用服务器，其优势是处理动态内容。前面最好加一层web服务器，如Nginx，它一秒可支持近2万的连接数。 秒杀时，前面设缓存服务器，用于计数，比如100件商品，可以先放进来500个人进来，如果超过这个数目的请求可以返回一个静态提示页面，比如活动已结束等 前500个请求走正常的下单流程，比如判断商品是否过期、可售数量是否大于0等等 这样处理的好处是可以有效消减大流量冲击，使请求变的平缓

这样做行不行呀？！可能一下被考官毙了。 我能想到的是在nodejs下，多核心cpu可以多开几个进程加大处理量。 因为是异步，用户提交后可以先提示处理中、计数器counter，前面多少人排除之类的，然后再出处理结果。 我在windows下的apche+php+fcgid，每秒也就120的处理量。6000的秒杀的确有点多。 看看大神如何给个最佳答案。

[showjim]

6000/s，如果仅仅是抢购逻辑，不需要集群，一台普通PC就可以了。 关键的问题是要把缓存做好，如果缓存做不好，600/s都是大问题。 如果需要一定的可靠性，那么需要备份服务器。

[dxqrr]

这个是永恒的问题

[tonylovexl]

预先准备好秒杀服务器，配备好每台服务器所拥有的商品数量，活动开始时设置好队列及长度，设置开关为true。 nginx做分发，策略为轮询。 每个服务器接到请求后在ArrayBlockingQueue中进行offer，成功则返回相应提示，一旦offer失败则将开关设置为false以阻止之后的请求。 offer失败或开关关闭均返回活动结束的提示。。。 这是个大体思路。。

[故人西辞_]

都是好高深的问题。

[姓氏弓长张]

直接distruptor 建队列 入和出都靠它了 -- 号称是最快的无锁交易，支持高并发--秒杀肯定单独服务提供队列 kryo 序列化 号称最快序列化，前段跟后端传输转换必备-- 其他服务与队列服务交互 超出队列部分入redis或者mongodb--因为队列不能设计的无限大，缺点类型简单，不过秒杀传输的信息也不可能整个对象，顶多也就是序列 再往前面就是nginx的分发，集群，不过后面的处理基本就是上面的 说到底秒杀最终还是单队列多处理服务，可以一笔单子全部一个流程处理，也可以一笔单子多流程组合处理，组合处理的好处是可以提供并发处理，但是失败补偿或者取消补偿都很麻烦。单流程就是仅可能把业务流程缩减到最短，不相关的东西均异步处理，通过其他队列，秒杀就专心做秒杀队列 这个是最近做秒杀的一点经验

[pww71]

看看这文章对你有帮助不 http://blog.csdn.net/pww71/article/details/25113303

[OK_boom]

引用 8 楼 u010784036 的回复:

集群属于空间换时间啦，会带来成本的提升，要优先考虑低成本方案。 做解决方案时，不仅仅要从技术角度考虑问题。 6000/s的请求，用缓存加排队机制啦，多两个队列，把每个请求的时间戳带上。

这个是好办法 。

[西西❤]

顶顶，先学习，

[xiaostar007]

mark，慢慢琢磨

[pww71]

http://blog.csdn.net/pww71/article/details/25113303 用这个库 也许更好