完整秒杀架构的设计

秒杀系统-情报背景

相信大家都接触过新浪微博、淘宝、京东等等这些访问量较为巨大的平台以及网站，针对于“高流量”、“高并发”来讲，更是我们【技术开发者】都要面临的的一个很难的“包袱”难题。哎，看来如果要在这行混下去，即使你可能没有接触高并发场景，也要自己创造“高并发”进行迎难而上，因为只有这样子我们才可以更进一步啊！

秒杀系统-情报介绍

对于今天我们要介绍的内容就属于高并发的一个最极端的场景之一：“秒杀”，这个名词一般会在“大促”的时候出现，当然也会在某些平台活动上出现，那么肯定会有小伙伴会说，秒杀系统要注意哪些问题啊！为啥会比较难呢，难在哪里啊！

秒杀系统- 特点分析

• 瞬时剧增：在某一个时刻开始进入流量（很少会有热身以及缓慢增长机制），秒杀时大量用户会在同一时间，抢购同一商品，网站瞬时流量激增。

• 僧多粥少：商品的库存是有限的，秒杀请求下的订单数量会远远大于库存数量，只有少部分用户能够秒杀成功。

• 资源锁定：秒杀业务流程比较简单，一般就是下订单减库存。库存就是用户争夺的“资源”，实际被消费的“资源”不能超过计划要售出的“资源”，也就是不能被“超卖”。

秒杀系统- 难度分析

它的难度就在于要完成一个“60-100分”的秒杀系统，那么它必须要要至少兼顾以下这三个方面，才算合格，这三个“恶魔”分别叫“服务可用性”、“数据一致性”和“快速响应性”，有点“苛刻”！

在我们现在的场景下，很难再去考虑一个非分布式系统的架构了。（分布式架构）相信大家都知道CAP理论吧！没事不知道也没关系，可见内容：

CAP理论又称CAP定理，它说的是在一个分布式系统中，服务（数据）层面的一致性（Consistency）、服务自身的可用性（Availability）、网络不同节点分区容错性（Partition tolerance）。

A和C相信大家从字面上都可以理解了，这里要声明一下比较陌生的P：它代表如果要保证不同的节点即使在网络出现问题的时候仍能够访问到数据，那么最直接的办法就是冗余赋值节点，否则一切都是空谈，所以作为一个分布式系统而言，无法忽略P，我们可以理解它就是A和C的基础。

CAP体系总结

• 只保证AC就是一个单体应用，根本不是分布式。意义当然有，在分布式出现之前都是这么搭系统。倘若这个系统的节点之一挂了，不会发生脑裂而是整个系统直接宕掉。

• 进一步说如果网络中存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。

• 为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

以上三者成为了“矛盾论”，而CAP原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

回到我们的主体：秒杀三要素，它们三个可不完全等同于CAP三要素，甚至比它们的要求更高，甚至是基于前三者的一个更高层次的水平要求。

服务的可用性（Availability）

服务可用性，是在于高并发流量的冲击下，仍然可以保持服务的可用性并且还要保证一直可以输出对外界的服务能力，不会造成宕机以及资源损坏，即使在内存和网络甚至硬件资源有限的情况下，也不会被击垮“死亡”。

比如就像你养鱼，你玩命的给鱼放饲料，而超过了鱼能够承受的量，它受不了了活活被噎死或者撑死了，这鱼就像你的系统一样，一定要保证鱼的健康啊！

数据的一致性（Consistency）

都知道，我们开发的程序以及现在多数的服务器，比如数据库，他们在处理数据的时候，很有可能会存在多个线程同时在修改同一行数据或者同一块内存，在Java角度而言本身也会存在不一致的问题，而在程序和中间件的角度而言，也是一样，会出现同一时刻在数据修改顺序的乱序化，以及数据的紊乱，造成数据的重复操作，造成与我们预期的设想不同。

• 除非你可以实现串行化，一条一条处理，不让它们同一时刻就行修改或者操作数据，这个是最本质且最安全的办法，但是也是最影响性能的办法。（悲观锁、同步队列）。

• 此外还有一种办法就是，时时刻刻在原子层级，也就是最接近底层的计算机修改数据的时候，或者在所有节点之间建立一个应用层级的中间汇总干路点（red