秒杀的本质
业务上：一场促销营销的活动
技术上：一种主动的DDos攻击，具备技术的不确定性和复杂度。
技术上对于秒杀有哪些优化方法呢？
- 丢弃订单
最早期，量太大扛不住，直接前端随机reject一些请求，返回抢单失败。简单有效
2. 优化吞吐
活动前期，提前准备一大批机器，服务化、分库分表搞定后端性能，让前端业务可以加一定量的机器，然后搞稳定性，依赖关系，容量规划，做弹性，提升吞吐量。
3. 异步队列
使用可堆积的消息队列或者内存消息队列，如果抢单具有强顺序性，那么都先进队列，然后取前N（秒杀数）个出来进行平滑处理，剩下的所有都作为失败批处理掉就行了。甚至还可以做一个定长的队列，再往里写直接提示失败。
4. 内存分配
一些具体的业务，也会考虑预热。提前在每个机器节点内存分配好库存数量，然后直接在内存里处理自己的库存数即可。
5. 拆分扩展
针对不同类型、不同商家、不同来源的商品，部署不同的前端促销集群，把压力分散。具体到每个商家，量就没那么大了。
6. 服务降级
越重要的抢单，大家越关心自己有没有抢到，也就是说抢到位置比处理完整个订单流程更有价值。比如12306抢票，只要告诉用户抢到票了，用户不会立马使用这张票，不关心是否订单是在一分钟处理完还是在一个小时处理完。
需要注意的是其中部分模式会导致销售不足或超卖。销售不足可以从抢购中加一些名单补发，也可以加一轮秒杀。超卖比较麻烦，所以一般会多备一些货，比如抢100个手机，备105个之类的。因为如果要解决1%的机率的超卖，从业务上解决比从技术上解决简单得多得多。
做系统架构设计的步骤
- 分析现状
产出：新需求文档，系统当前现状的相关文档和设计图，可行性分析文档
2. 寻找路径
产出：设计方案初稿，关键问题分析，关键技术选型报告，POC验证的场景设计文档和DEMO，测试/压测结果
3. 确定方案
产出：架构设计方案和设计图终稿，组织会议同步和宣贯。
系统设计文档
- 需求分析
- 整体设计
- 系统架构图
- 业务架构图
- 技术架构图
- 数据架构图
- 部署架构图
文档结构示例：
技术选型的方法
原则上，综合考虑相对成熟稳定的合适技术。符合公司技术发展路线和选型规范。
方法：基于关键场景编写case，实现demo，验证多种类似技术的各项指标。