共计 5915 个字符，预计需要花费 15 分钟才能阅读完成。
电商的秒杀和抢购，对咱们来说，都不是一个生疏的货色。然而，从技术的角度来说，这对于 Web 零碎是一个微小的考验。当一个 Web 零碎，在一秒钟内收到数以万计甚至更多申请时，零碎的优化和稳固至关重要。这次咱们会关注秒杀和抢购的技术实现和优化，同时，从技术层面揭开，为什么咱们总是不容易抢到火车票的起因？
一、大规模并发带来的挑战
在过来的工作中，我已经面对过 5w 每秒的高并发秒杀性能，在这个过程中，整个 Web 零碎遇到了很多的问题和挑战。如果 Web 零碎不做针对性的优化，会轻而易举地陷入到异样状态。咱们当初一起来探讨下，优化的思路和办法哈。
1. 申请接口的正当设计
一个秒杀或者抢购页面，通常分为 2 个局部，一个是动态的 HTML 等内容，另一个就是参加秒杀的 Web 后盾申请接口。
通常动态 HTML 等内容，是通过 CDN 的部署，个别压力不大，外围瓶颈实际上在后盾申请接口上。这个后端接口，必须可能反对高并发申请，同时，十分重要的一点，必须尽可能“快”，在最短的工夫里返回用户的申请后果。为了实现尽可能快这一点，接口的后端存储应用内存级别的操作会更好一点。依然间接面向 MySQL 之类的存储是不适合的，如果有这种简单业务的需要，都倡议采纳异步写入。
当然，也有一些秒杀和抢购采纳“滞后反馈”，就是说秒杀当下不晓得后果，一段时间后才能够从页面中看到用户是否秒杀胜利。然而，这种属于“偷懒”行为，同时给用户的体验也不好，容易被用户认为是“暗箱操作”。
2. 高并发的挑战：肯定要“快”
咱们通常掂量一个 Web 零碎的吞吐率的指标是 QPS（Query Per Second，每秒解决申请数），解决每秒数万次的高并发场景，这个指标十分要害。举个例子，咱们假如解决一个业务申请均匀响应工夫为 100ms，同时，零碎内有 20 台 Apache 的 Web 服务器，配置 MaxClients 为 500 个（示意 Apache 的最大连贯数目）。
那么，咱们的 Web 零碎的实践峰值 QPS 为（理想化的计算形式）：
20*500/0.1 = 100000（10 万 QPS）
咦？咱们的零碎仿佛很弱小，1 秒钟能够解决完 10 万的申请，5w/ s 的秒杀仿佛是“纸老虎”哈。理论状况，当然没有这么现实。在高并发的理论场景下，机器都处于高负载的状态，在这个时候均匀响应工夫会被大大增加。
就 Web 服务器而言，Apache 关上了越多的连贯过程，CPU 须要解决的上下文切换也越多，额定减少了 CPU 的耗费，而后就间接导致均匀响应工夫减少。因而上述的 MaxClient 数目，要依据 CPU、内存等硬件因素综合思考，相对不是越多越好。能够通过 Apache 自带的 abench 来测试一下，取一个适合的值。而后，咱们抉择内存操作级别的存储的 Redis，在高并发的状态下，存储的响应工夫至关重要。网络带宽尽管也是一个因素，不过，这种申请数据包个别比拟小，个别很少成为申请的瓶颈。负载平衡成为零碎瓶颈的状况比拟少，在这里不做探讨哈。
那么问题来了，假如咱们的零碎，在 5w/ s 的高并发状态下，均匀响应工夫从 100ms 变为 250ms（理论状况，甚至更多）：
20*500/0.25 = 40000（4 万 QPS）
于是，咱们的零碎剩下了 4w 的 QPS，面对 5w 每秒的申请，两头相差了 1w。
而后，这才是真正的恶梦开始。举个例子，高速路口，1 秒钟来 5 部车，每秒通过 5 部车，高速路口运作失常。忽然，这个路口 1 秒钟只能通过 4 部车，车流量依然仍旧，后果必然呈现大塞车。（5 条车道突然变成 4 条车道的感觉）
同理，某一个秒内，20*500 个可用连贯过程都在满负荷工作中，却依然有 1 万个新来申请，没有连贯过程可用，零碎陷入到异样状态也是预期之内。
其实在失常的非高并发的业务场景中，也有相似的状况呈现，某个业务申请接口呈现问题，响应工夫极慢，将整个 Web 申请响应工夫拉得很长，逐步将 Web 服务器的可用连接数占满，其余失常的业务申请，无连贯过程可用。
更可怕的问题是，是用户的行为特点，零碎越是不可用，用户的点击越频繁，恶性循环最终导致“雪崩”（其中一台 Web 机器挂了，导致流量扩散到其余失常工作的机器上，再导致失常的机器也挂，而后恶性循环），将整个 Web 零碎拖垮。
3. 重启与过载爱护
如果零碎产生“雪崩”，贸然重启服务，是无奈解决问题的。最常见的景象是，启动起来后，立即挂掉。这个时候，最好在入口层将流量回绝，而后再将重启。如果是 redis/memcache 这种服务也挂了，重启的时候须要留神“预热”，并且很可能须要比拟长的工夫。
秒杀和抢购的场景，流量往往是超乎咱们零碎的筹备和设想的。这个时候，过载爱护是必要的。如果检测到零碎满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简略的形式，然而，这种做法是被用户“千夫所指”的行为。更适合一点的是，将过载爱护设置在 CGI 入口层，疾速将客户的间接申请返回。
二、舞弊的伎俩：防御与防守
秒杀和抢购收到了“海量”的申请，实际上外面的水分是很大的。不少用户，为了“抢“到商品，会应用“刷票工具”等类型的辅助工具，帮忙他们发送尽可能多的申请到服务器。还有一部分高级用户，制作弱小的主动申请脚本。这种做法的理由也很简略，就是在参加秒杀和抢购的申请中，本人的申请数目占比越多，胜利的概率越高。
这些都是属于“舞弊的伎俩”，不过，有“防御”就有“防守”，这是一场没有硝烟的战斗哈。
1. 同一个账号，一次性收回多个申请
局部用户通过浏览器的插件或者其余工具，在秒杀开始的工夫里，以本人的账号，一次发送上百甚至更多的申请。实际上，这样的用户毁坏了秒杀和抢购的公平性。
这种申请在某些没有做数据安全解决的零碎里，也可能造成另外一种毁坏，导致某些判断条件被绕过。例如一个简略的支付逻辑，先判断用户是否有参加记录，如果没有则支付胜利，最初写入到参加记录中。这是个非常简单的逻辑，然而，在高并发的场景下，存在深深的破绽。多个并发申请通过负载平衡服务器，调配到内网的多台 Web 服务器，它们首先向存储发送查问申请，而后，在某个申请胜利写入参加记录的时间差内，其余的申请获查问到的后果都是“没有参加记录”。这里，就存在逻辑判断被绕过的危险。
应答计划：
在程序入口处，一个账号只容许承受 1 个申请，其余申请过滤。不仅解决了同一个账号，发送 N 个申请的问题，还保障了后续的逻辑流程的平安。实现计划，能够通过 Redis 这种内存缓存服务，写入一个标记位（只容许 1 个申请写胜利，联合 watch 的乐观锁的个性），胜利写入的则能够持续加入。
或者，本人实现一个服务，将同一个账号的申请放入一个队列中，解决完一个，再解决下一个。
2. 多个账号，一次性发送多个申请
很多公司的账号注册性能，在倒退晚期简直是没有限度的，很容易就能够注册很多个账号。因而，也导致了呈现了一些非凡的工作室，通过编写主动注册脚本，积攒了一大批“僵尸账号”，数量宏大，几万甚至几十万的账号不等，专门做各种刷的行为（这就是微博中的“僵尸粉“的起源）。举个例子，例如微博中有转发抽奖的流动，如果咱们应用几万个“僵尸号”去混进去转发，这样就能够大大晋升咱们中奖的概率。
这种账号，应用在秒杀和抢购里，也是同一个情理。例如，iPhone 官网的抢购，火车票黄牛党。
应答计划：
这种场景，能够通过检测指定机器 IP 申请频率就能够解决，如果发现某个 IP 申请频率很高，能够给它弹出一个验证码或者间接禁止它的申请：
弹出验证码，最外围的谋求，就是分辨出实在用户。因而，大家可能常常发现，网站弹出的验证码，有些是“鬼神乱舞”的样子，有时让咱们根本无法看清。他们这样做的起因，其实也是为了让验证码的图片不被轻易辨认，因为弱小的“主动脚本”能够通过图片辨认外面的字符，而后让脚本主动填写验证码。实际上，有一些十分翻新的验证码，成果会比拟好，例如给你一个简略问题让你答复，或者让你实现某些简略操作（例如百度贴吧的验证码）。
间接禁止 IP，实际上是有些粗犷的，因为有些实在用户的网络场景恰好是同一进口 IP 的，可能会有“误伤“。然而这一个做法简略高效，依据理论场景应用能够取得很好的成果。
3. 多个账号，不同 IP 发送不同申请
所谓道高一尺，魔高一丈。有防御，就会有防守，永不休止。这些“工作室”，发现你对单机 IP 申请频率有管制之后，他们也针对这种场景，想出了他们的“新防御计划”，就是一直扭转 IP。
有同学会好奇，这些随机 IP 服务怎么来的。有一些是某些机构本人占据一批独立 IP，而后做成一个随机代理 IP 的服务，有偿提供给这些“工作室”应用。还有一些更为光明一点的，就是通过木马黑掉普通用户的电脑，这个木马也不毁坏用户电脑的失常运作，只做一件事件，就是转发 IP 包，普通用户的电脑被变成了 IP 代理进口。通过这种做法，黑客就拿到了大量的独立 IP，而后搭建为随机 IP 服务，就是为了挣钱。
应答计划：
说实话，这种场景下的申请，和实在用户的行为，曾经基本相同了，想做分辨很艰难。再做进一步的限度很容易“误伤“实在用户，这个时候，通常只能通过设置业务门槛高来限度这种申请了，或者通过账号行为的”数据挖掘“来提前清理掉它们。
僵尸账号也还是有一些独特特色的，例如账号很可能属于同一个号码段甚至是连号的，活跃度不高，等级低，材料不全等等。依据这些特点，适当设置参加门槛，例如限度参加秒杀的账号等级。通过这些业务伎俩，也是能够过滤掉一些僵尸号。
4. 火车票的抢购
看到这里，同学们是否明确你为什么抢不到火车票？如果你只是老老实实地去抢票，真的很难。通过多账号的形式，火车票的黄牛将很多车票的名额占据，局部弱小的黄牛，在解决验证码方面，更是“技高一筹“。
高级的黄牛刷票时，在辨认验证码的时候应用实在的人，两头搭建一个展现验证码图片的直达软件服务，真人浏览图片并填写下实在验证码，返回给直达软件。对于这种形式，验证码的爱护限度作用被破除了，目前也没有很好的解决方案。
因为火车票是依据身份证实名制的，这里还有一个火车票的转让操作形式。大抵的操作形式，是先用买家的身份证开启一个抢票工具，继续发送申请，黄牛账号抉择退票，而后黄牛买家胜利通过本人的身份证购票胜利。当一列车厢没有票了的时候，是没有很多人盯着看的，况且黄牛们的抢票工具也很弱小，即便让咱们看见有退票，咱们也不肯定能抢得过他们哈。
最终，黄牛顺利将火车票转移到买家的身份证下。
解决方案：
并没有很好的解决方案，惟一能够动心理的兴许是对账号数据进行“数据挖掘”，这些黄牛账号也是有一些独特特色的，例如常常抢票和退票，节假日异样沉闷等等。将它们剖析进去，再做进一步解决和甄别。
三、高并发下的数据安全
咱们晓得在多线程写入同一个文件的时候，会存现“线程平安”的问题（多个线程同时运行同一段代码，如果每次运行后果和单线程运行的后果是一样的，后果和预期雷同，就是线程平安的）。如果是 MySQL 数据库，能够应用它自带的锁机制很好的解决问题，然而，在大规模并发的场景中，是不举荐应用 MySQL 的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面管制不慎，会产生发送过多的状况。咱们也已经据说过，某些电商搞抢购流动，买家胜利拍下后，商家却不抵赖订单无效，回绝发货。这里的问题，兴许并不一定是商家忠厚，而是零碎技术层面存在超发危险导致的。
1. 超发的起因
假如某个抢购场景中，咱们一共只有 100 个商品，在最初一刻，咱们曾经耗费了 99 个商品，仅剩最初一个。这个时候，零碎发来多个并发申请，这批申请读取到的商品余量都是 99 个，而后都通过了这一个余量判断，最终导致超发。（同文章后面说的场景）
在下面的这个图中，就导致了并发用户 B 也“抢购胜利”，多让一个人取得了商品。这种场景，在高并发的状况下非常容易呈现。
2. 乐观锁思路
解决线程平安的思路很多，能够从“乐观锁”的方向开始探讨。
乐观锁，也就是在批改数据的时候，采纳锁定状态，排挤内部申请的批改。遇到加锁的状态，就必须期待。
尽管上述的计划确实解决了线程平安的问题，然而，别忘记，咱们的场景是“高并发”。也就是说，会很多这样的批改申请，每个申请都须要期待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种申请就会死在那里。同时，这种申请会很多，霎时增大零碎的均匀响应工夫，后果是可用连接数被耗尽，零碎陷入异样。
3.FIFO 队列思路
那好，那么咱们略微批改一下下面的场景，咱们间接将申请放入队列中的，采纳 FIFO（First Input First Output，先进先出），这样的话，咱们就不会导致某些申请永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。
而后，咱们当初解决了锁的问题，全副申请采纳“先进先出”的队列形式来解决。那么新的问题来了，高并发的场景下，因为申请很多，很可能一瞬间将队列内存“撑爆”，而后零碎又陷入到了异样状态。或者设计一个极大的内存队列，也是一种计划，然而，零碎解决完一个队列内申请的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的申请会越积攒越多，最终 Web 零碎均匀响应时候还是会大幅降落，零碎还是陷入异样。
4. 乐观锁思路
这个时候，咱们就能够讨论一下“乐观锁”的思路了。乐观锁，是绝对于“乐观锁”采纳更为宽松的加锁机制，大都是采纳带版本号（Version）更新。实现就是，这个数据所有申请都有资格去批改，但会取得一个该数据的版本号，只有版本号合乎的能力更新胜利，其余的返回抢购失败。这样的话，咱们就不须要思考队列的问题，不过，它会增大 CPU 的计算开销。然而，综合来说，这是一个比拟好的解决方案。
5. 缓存服务器
Redis 分布式要保证数据都能可能均匀的缓存到每一台机器，首先想到的做法是对数据进行分片，因为 Redis 是 key-value 存储的，首先想到的是 Hash 分片，可能的做法是对 key 进行哈希运算，失去一个 long 值对分布式的数量取模会失去一个一个对应数据库的一个映射，没有读取就能够定位到这台数据库
有很多软件和服务都“乐观锁”性能的反对，例如 Redis 中的 watch 就是其中之一。通过这个实现，咱们保障了数据的平安。
四、小结
互联网正在高速倒退，应用互联网服务的用户越多，高并发的场景也变得越来越多。电商秒杀和抢购，是两个比拟典型的互联网高并发场景。尽管咱们解决问题的具体技术计划可能千差万别，然而遇到的挑战却是类似的，因而解决问题的思路也殊途同归。
集体整顿并发解决方案。
a. 利用层面：读写拆散、缓存、队列、集群、令牌、零碎拆分、隔离、系统升级（可程度扩容方向）。
b. 工夫换空间：升高单次申请工夫，这样在单位工夫内零碎并发就会晋升。
c. 空间换工夫：拉长整体解决业务工夫，换取后盾零碎容量空间。
