一、问题解析
说起秒杀，我想你肯定不陌生，这两年，从双十一购物到春节抢红包，再到 12306 抢火车票，"秒杀"的场景处处可见。简单来说，秒杀就是在同一个时刻有大量的 请求争抢购买同一个商品并完成交易的过程，用技术的行话来说就是大量的并发读 和并发写。
不管是哪一门语言，并发都是程序员们最为头疼的部分。同样，对于一个软件而言 也是这样，你可以很快增删改查做出一个秒杀系统，但是要让它支持高并发访问就 没那么容易了。比如说，如何让系统面对百万级的请求流量不出故障？如何保证高 并发情况下数据的一致性写？完全靠堆服务器来解决吗？这显然不是最好的解决 方案。
在我看来，秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。
今天，我们就来聊聊，如何在满足一个良好架构的分布式系统基础上，针对秒杀这种业务做到极致的性能改进。如何才能更好地理解秒杀系统呢？我觉得作为一个程序员，你首先需要从高维度出发，从整体上思考问题。在我看来，秒杀其实主要解决两个问题，一个是并发读，一个是并 发写。并发读的核心优化理念是尽量减少用户到服务端来"读"数据，或者让他们读更少的数据；并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。另外，我们还要针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。
而从一个架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系统，在整个用户请求路径上从浏览器到服务端我们要遵循几个原则，就是要保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。这些关键点我会在后面的文章里重点讲解。
**其实，秒杀的整体架构可以概括为"稳、准、快"几个关键字。**所谓"稳"，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，就是超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。
然后就是"准"，就是秒杀 10 台 iPhone，那就只能成交 10 台，多一台少一台都不行。
一旦库存不对，那平台就要承担损失，所以"准"就是要求保证数据的一致性。
最后再看"快"，"快"其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。
所以从技术角度上看"稳、准、快"，就对应了我们架构上的高可用、一致性和高性能的要求，我们的专栏也将主要围绕这几个方面来展开，具体如下。
**高性能。**秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。
本专栏将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、
服务端的极致优化这 4 个方面重点介绍。
**一致性。**秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在
同一时刻被很多倍的请求同时来减库存，减库存又分为"拍下减库存""付款减库
存"以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想
而知。因此，我将用一篇文章来专门讲解如何设计秒杀减库存方案。
**高可用。**虽然我介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑
不到的情况，所以要保证系统的高可用和正确性，我们还要设计一个 PlanB 来兜底，
以便在最坏情况发生时仍然能够从容应对。专栏的最后，我将带你思考可以从哪些
环节来设计兜底方案。
二、粉丝福利
我是浮生，一个工作十四年经验的Java程序员！
最近很多同学问我有没有java学习资料，我根据我从小白到架构师多年的学习经验整理出来了一份80W字面试解析文档、简历模板、学习路线图、java必看学习书籍 、 需要的小伙伴 可以关注我
公众号：" 灰灰聊架构**"， 回复暗号："** 321**"即可获取**
