原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。css
秒杀，就像是计划经济的菜市场，过客匆匆，你来我往。熙熙攘攘一阵子，事后只留下冷清寂寞的大街。html
且看一个卖鹅的故事。↓↓↓前端
就在昨天。天刚蒙蒙亮，大概是”早晨五六点钟“，几个程序员顶着蓬松的头发，下班结伴而行。这个时候，街上的路灯尚未灭的干脆。几个锻炼的老大爷，叉着腰，身体前倾，弯成一张弓。nginx
因此，胡同岔口里一个卖鹅的小贩，就显得特别的显眼。就见一大群鹅被关在诺大的笼子里，扑棱着翅膀。有几只精力旺盛的，伸长脖子呱呱叫着，小贩听得心烦，就用手中的树枝敲它们的脑壳。程序员
扫码关注“不才黄某”数据库
回复“资源”swift
获取1T视频教程及电子书后端
小贩歪了歪嘴，又用眼角余光扫了下手机，已经五点六十了。就在这时，四面八方就围上来一群大妈，就像是从地底冒出来同样。刚开始还悠然的靠拢，等看到笼子果真有一群鹅，就捏着手里的小包，争先恐后的小跑起来。浏览器
这来势汹汹的阵势，吓了你们一跳，程序员们站住不动了。大爷的腰也不弯了，就连那些聒噪的鹅，也不叫了。缓存
很快就有大妈帮小贩打开了笼子，不容分说，扯住一只鹅的脖子就拖了出来。接着就有另一只手扯住了另外一只鹅的翅膀。一会儿人喊鹅嘶，吵吵嚷嚷，下起了鹅毛大雪。不一下子，全部的鹅就都在大妈们手里了。但也有更多没获得鹅的大妈，用手绢在一旁抹着悔恨嫉妒的泪水。
王大妈最高兴了，她手大，抓了三只，其中两只倒霉的鹅被她握在一只手里，脖子拧成一根麻花。也有被捏死的鹅，犯了鹅命的大妈就不想要了，但有更多的大妈根本就不嫌弃。
小贩长吁一口气，招数确实有效，就搞了个秒杀，这群犯了瘟病的鹅，瞬间被低价处理了。
这一切全落在了躲在一旁的程序员们眼里。等人散的差很少了，他们把小贩围上，其中一个眼尖，喊了出来：”这卖鹅的，不是xjjdog么？“
“xjjdog正是在下。咱们不如找个油条馆子，坐下来等我给大家，慢慢道来。”
秒杀难点
秒杀，这么酷炫的词语，注定了不是小绵羊，而是洪水猛兽。3w块钱和3000w的系统差异，想要了解一下么？
任何不对等的状况，都会产生危机，对业务系统来讲一样的道理。秒杀系统难，主要集中在如下几点。
一、流量超出承载范围
秒杀，通常归做突发流量，日常一天的请求量，可能集中在几秒以内就能完成。秒杀资源的稀缺，也会形成资源成为热点，发生多人争抢的局面。想象一下小长假的高速公路收费站，就可以了解到一无所获的参与者有多火大。
二、资源冲突
若是采用传统的数据库进行数据存储，对同一资源的争抢，就会面临严重的锁冲突问题。通常是经过一个前置的，速度更快的存储顶在前面，这就涉及到源库和目标库的数据同步问题。
从商品资源的上架，到秒杀的完成，会经历一个短暂的混沌状态，出现数据不一致的状况。在请求量很是集中的状况下，还会产生并发问题，个体的行为和结果，是不可预测的。
三、难度高
秒杀对基础设施和技术的要求也是比较高的，从接入层到缓存到存储层，以及安全方面的考虑，须要多个组件的参与，并且每一个组件都须要进行优化。
总之，吵吵闹闹一场，最终会归于平静。为了秒杀而准备的硬件资源，不能就放在那里闲置了吧，因此通常还会有一个资源释放阶段，这是后话，咱们不作过多关注。
业务三阶段
通常的，秒杀业务会分为三个阶段。其中，抢购阶段，就是咱们常说的秒杀业务。
一、准备阶段
在准备阶段，除了硬件和软件系统的准备，通常会有一个活动上的预热，互联网运营会将相似电线杆上小广告的东西，广而发之。从前，有个客户搞了个秒杀活动，100个库存99我的参与，99我的有90个内部员工，尴尬呵呵。
若是有本身的app，经过通知、订阅，会达到比较好的效果。若是涉及的商品多，参与人数巨大，会对数据进行预处理，进行提早预热。一切准备稳当，就能够抽根烟，等着倒计时了。
二、抢购
俗话说，台上一分钟，台下十年功。秒杀开始，会有大量的瞬间请求涌入，该到了上台表演的时候了。这个阶段，咱们的每一个系统和模块，都会迅速轮转起来，任何一个点考虑不周，都会形成本次秒杀活动的失败，因此关键组件要保证极高可用。
三、结束清算
上面也说过，秒杀会有一个短暂的混沌态。清算阶段，就要完成数据的最终一致性，落库动做可能会持续很多时间。可能有的用户，在付款的那一刻，后悔了，商品要从新归位回仓。回仓后的商品通常会再次售卖，好比火车票，30分钟后能够再抢一次；有的商品就能够被锁定下架，永远消失了。
制约原理
这里，咱们大致说一下秒杀系统在技术方面的基本制约原理，详细的描述和代码，咱们在后面的章节里进行说明。
数据预热
有的系统进行秒杀的，可能就那么几件商品，手工录入都玩得转。对于平台类型，或者用户量巨大的app，秒杀的商品就再也不那么简单。
中间，会进行一些数据的合并，或者二维展开，也就是准备秒杀的数据。这些数据进行处理以后，会提早进入到秒杀系统进行数据预热。
秒杀阶段进行的是否顺利，得看数据准备的是否合理。
请求承载
这是请求的最外层，属于接入层。作的好的系统，可以在接入层就屏蔽大部分请求，极大的减轻后端服务的压力。
链接数承载
对于接入层来讲，首先一个挑战就是链接数。通常互联网的接入层，就是lvs+nginx。这里会涉及到对操做系统的优化，以及对于nginx自己的优化。
并发承载
对于落到某台机器上的请求，依然会存在并发高的问题。线程池使用要合理，怎么去进行过滤，合并等，有必定挑战。
负载均衡
请求要能真正的作到均衡，不能产生热点问题。好比nginx的ip_hash，虽然能必定程度上规避分布式session问题，但请求会不均衡。
重试？
秒杀业务不要配置重试，会加重系统负载。请求失败？那就再来一次。
系统隔离
秒杀业务占用的系统资源，和正常运行的系统严重不对等。若是有条件，秒杀系统的硬件和服务环境，要与正常业务系统进行必定程度的隔离。要提早评估对其余服务的压力，避免影响正常业务。
CDN
对于html，js，css，图片等内容，占用了大量的带宽。若是将这些资源都放在本身的服务器上，流量到来时会迅速占满带宽，形成正常的秒杀请求没法完成。CDN能够有效解决这个问题。剩下的请求，就是真正的秒杀业务。
减少请求包
对网络请求包，要进行大量优化。能够开gzip压缩，资源自己也进行压缩，去掉请求包中的无用信息，对网络报文进行精简。
请求拦截
秒杀系统一个很是大的原则，就是要把尽可能多的无效请求，拦截在外部。请求拦截，能够分为上游拦截和业务拦截。
上游拦截
拦截方面，存在一个全局的设置。当系统判断以及达到瓶颈阶段，就能够经过全局限流方式进行服务降级，对于一些次级服务，要进行熔断处理。对于前端来讲，也是须要进行一些优化的。好比浏览器缓存，防重入验证等，可以拦截数量可观的请求。
业务拦截
除了一些全局的限制，对于大部分请求来讲，和用户是息息相关的。一个用户，可能会频繁的刷新，或者绕过前端，直接使用软件调用后端接口。这些用户的非法请求，也要进行拦截。
同时，用户对资源的争夺，也不该该无限等待。好比100个库存的商品，第1w个请求到来的时候，就不须要再排队等待了，直接返回秒杀完毕就ok了。
排队方面，会用到jvm内排队，也会用到外部的消息队列，mq，进行请求的缓冲。
数据缓存
缓存，多是秒杀系统中最重要的一个组件了。从前端缓存，到jvm缓存，再到分布式缓存，都会对系统性能产生数量级的提高。值得注意的是，因为秒杀系统严重依赖缓存系统，因此缓存系统须要作高可用。
缓存的读操做，要考虑数据的加载和同步。写请求，就要考虑数据的合并与并发写入，数据的一致性等。虽然缓存的速度比起DB来，快了不少不少，但它的性能老是有瓶颈的，相关代码要着重优化。
安全
技术的门槛愈来愈低，二年级的小学生都开课教swift了，写个秒杀插件什么的，不费吹灰之力。秒杀系统的安全性比较重要，应该说和钱打交道的系统，都是容易出问题的。你要是想薅羊毛，认准营销、秒杀业务，准没错。
要尽可能提升做弊门槛，好比url动态化，从入口就隔绝了大部分攻击；验证码，只会增长攻击者的成本。有些安全性级别较高的，还会增长风控规则，好比同一ip请求过多封禁、帐号注册日期三天以内不容许参与、秒杀的门槛必须是金牌会员等。
我曾经经历过一次，对方原本是一个算加减乘除的验证码，脚本都写好了。结果秒杀前5分钟，验证码12306附体，xjjdog直接放弃了。
躲在幕后的DB
在整个秒杀系统中，传统的DB，只能灰溜溜的躲在幕后（小流量除外）。我要是DB，也会躲在后面瑟瑟发抖。
DB的数据，要提早载入到秒杀系统中进行运算，秒杀完毕，还要把狼藉的数据进行落地与清算。在笔者见过的很多秒杀场景中，甚至不须要DB的参与，真是艺高人胆大。
这就引伸出另一个问题。假如缓存系统出现问题，请求要不要穿透呢？个人建议是，不须要。非正常的请求，会瞬间压垮DB，产生更加严重的数据错乱问题，假如没有作隔离，后果会更狂野。与其错了，不如认怂，乖乖的复盘写故障报告吧。
End
秒杀，夺宝，p2p，是互联网创造的，钱袋子三大杀手。
我要说一些隐秘的事情。前不久，个人这群鹅原本好好的，结果混进一只长了瘟病的鸡，没几天就病恹恹的不行了，要是扔了怪惋惜的。这卖鹅的时间线，也搞的十分紧凑。
就在昨天，我就放出了有一批廉价鹅要处理的消息。为了让更多的大妈相信，我按照市面价格打了个五折，其实打一折都能出手（抖音上那种鹅不敢卖）。5点多我就给几只快不成的鹅，注射了兴奋剂，但愿它们能多撑一会，还拿了根树枝敲它们的脑壳进行确认。不是我自信，这种场景，就是死鹅也卖得出去。但死的多了，毕竟很差。为了限制拥挤的人流，我特地把笼子口的铁丝角给漏出来，很多大妈划破了手都没把鹅抓到，我也搞不清她们是不幸，仍是幸运。
是谁首先创造的秒杀？真是天才。和饥饿营销同样，收的是智商税吧。哈哈哈~
本文分享自微信公众号 - 码农沉思录（code-thinker）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。