抢购为什么难，需要怎么做？

提到秒杀抢购，众说纷纭的有两类，那些趾高气扬的人总把抢购失败者当傻子，好兜售些"假黑科技"，要么还有一类人，他们展示各种你根本听不懂的服务器后端技术，CDN，锁单，Redis缓存之类。

说网速，手速的，其实也是在说运气，你网速不好，手速慢，隔壁大概率也好不到哪去，这不是问题的根本。菊花转半天出来一个无库存，这实际上是一个错误的设计并不是你的问题，大家陷入细节，没人看得到而已，更别说改进。

你不得不接收菊花转半天给你个没有库存的结论，但同时，你也有成功的概率，概率有多大，全靠运气。

我的方法就是不参加抢购，如果非要参加，我宁可避开高峰而去捡漏。

具体做法就是抢购前5分钟只点击一次，听天由命，若失败不会再试，或者仅再试两三次，但肯定不会太多。然后去做自己的事，闲暇时，再试一次两三次，若失败不再试，继续做自己的事。没事试一下，成功的概率就会比较大。

几乎所有商户，从12306到小区门口小超市，都不会一次性放量所有商品，一般会分好几批，每一批都会故意留一些“漏”。比如1000双皮鞋，8点开抢，商家会放480双，然后5分钟或10分钟或20分钟后再放20双，12点时放280双，5分钟或10分钟后再放20双…几乎你用过的平台，差不多都是这个路数。

捡漏不仅基于分批放量，还有一点，总会有人付款失败的，手机没电的，断网的，退货的。

不要拼手速重复点击是关键，在你们给服务器带来DDoS的同时，你们也把自己DDoS了，如果你折腾一二十分钟到手抖，心情极差，你一天的正常工作还能做好吗？

现在说下后端设计。

网购只是线上服务的一种，近年来的相关技术都集中在树木而非森林，大家花大量的精力去优化一个锁，却忘了真正重要的是“让用户快速成功，否则快速失败！”。

快速成功否则快速失败在均匀流量下根本不是问题，服务并未过载，P999成功率显然很高，但系统负载有个或弹性或确切的阈值，一旦过载，哪怕只是稍微过载，失败率就大大增加，体现到业务指标，就是用户体验下降。

这个问题的根源在于线上服务完全模拟了线下服务，这是不对的。

线下服务可以平滑地天然限流，比如商场促销，你花在路上的时间，堵车，停车，等红绿灯，这些限流是自然的，但线上服务不同，任意数量的请求允许在任意时间到达任意服务器，所谓的限流只是将过载的请求丢掉，但重试马上就会到来。

网络协议栈在多个层次都会重试，比如TCP的SYN丢了，马上就会过来一个新的SYN，TCP并不知道是过载了，重试报文会加剧过载，最终让系统有效处理能力指数级下降，如果TCP知道是过载导致丢包，源抑制会让系统处理更多有效请求而不是处理过载。

交换节点和服务器对拥塞缺乏源抑制，这是线上服务很容易过载且很难恢复的根源，拥塞反馈到源需要RTT级别的时间，这段时间对于抢购这种模式的突发流量而言，足以让事情不可收拾，轻则大量用户失败，重则服务器被打垮。

用户的重试行为加剧了过载。虽然很多前端限制了同一用户在固定时间段的重试次数，但模棱两可的错误提示还是会触发用户在解除限制后重新碰碰运气，因为他们不知道自己已彻底失败。

用户等了好久却被告知失败，这种很差的体验不是因为服务器真的在“努力判断”。全局上看，服务器早就知道你失败了，只是没告诉你而已，为什么没告诉你，因为服务器架构都是基于微服务交互的， 每一个微服务交互的不是你这个终端APP，而是它的上游或下游微服务，这就是我说的为什么根源在只见树木，不见森林。

问题不是不好解决，只是没人在乎。如果后端的一切处理逻辑都以用户体验为基，事情就好办。抢购只给每个请求一次机会，在服务端处理的任何环节失败即出局，不再重试该环节，不再等待，第一时间直接向用户反馈“彻底失败”。至于每个请求一次机会造成的没有卖出去的东西，加入后续的放量，这样既提升了用户体验，也使售卖更加平滑，降低了突发。

最后，谈一个有效的措施，搭建隧道。

请看下面的图：
​
如果你有一条明确的更好的线路到达服务器，那就通过那条线路搭隧道或建代理，它肯定比通过公共互联网要好，哪怕接入了CDN，你要知道那个CDN也不是你独享的。一切以RTT，bandwidth测量为准。

最近买东西成了问题，团购，肉菜，抢啤酒，很多人毕其一天干这个事，严重影响了工作和生活，我的观点是即便买不到东西，也不能影响正常工作和生活，没有什么任何是必须完成的，生活要柔性，生活要能接受有损。关于抢购，写一点自己的经验。

浙江温州皮鞋湿，下雨进水不会胖。