秒杀特点及思路?

　　短时间内，大量用户涌入，集中读和写有限的库存。

　　尽量将请求拦截在系统上游(越上游越好);读多写少的多使用缓存(缓存抗读压力);

　　从分层角度理解?

　　层层拦截，将请求尽量拦截在系统上游，避免将锁冲落到数据库上。

　　第一层：客户端优化

　　产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求;JS层面，限制用户在x秒之内只能提交一次请求，比如微信摇一摇抢红包。基本可以拦截80%的请求。

　　第二层：站点层面的请求拦截(nginx层，写流控模块)

　　怎么防止程序员写for循环调用，有去重依据么? IP? cookie-id? …想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存存储(这样计数会不准，但最简单，比如guava本地缓存)。一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。对于5s内的无效请求，统一返回错误提示或错误页面。

　　这个方式拦住了写for循环发HTTP请求的程序员，有些高端程序员(黑客)控制了10w个肉鸡，手里有10w个uid，同时发请求(先不考虑实名制的问题，小米抢手机不需要实名制)，这下怎么办，站点层按照uid限流拦不住了。

　　第三层：服务层拦截

　　方案一：写请求放到队列中，每次只透有限的写请求到数据层，如果成功了再放下一批，直到库存不够，队列里的写请求全部返回“已售完”。

　　方案二：或采用漏斗机制，只放一倍的流量进来，多余的返回“已售完”，把写压力转换成读压力。读请求，用cache，redis单机可以抗10W QPS,用异步线程定时更新缓存里的库存值。 、

　　还有提示“模糊化”，比如火车余票查询，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票。

　　第四层：数据库层

　　浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。 db基本就没什么压力了，通过自身锁机制来控制，避免出现超卖。

　　从架构角度理解?

　　高性能

　　动静分离 秒杀过程中你是不需要刷新整个页面的，只有时间在不停跳动。这是因为一般都会对大流量的秒杀系统做系统的静态化改造，即数据意义上的动静分离。动静分离三步走：

　　数据拆分;静态缓存;数据整合。

　　热点优化 数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。热点识别和隔离不仅对“秒杀”这个场景有意义，对其他的高性能分布式系统也非常有参考价值。

　　系统优化

　　减少序列化：减少 Java 中的序列化操作可以很好的提升系统性能。序列化大部分是在 RPC 阶段发生，因此应该尽量减少 RPC 调用，一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减少不同应用之间的 RPC 调用(微服务设计规范)

　　直接输出流数据：只要涉及字符串的I/O操作，无论是磁盘 I/O 还是网络 I/O，都比较耗费 CPU 资源，因为字符需要转换成字节，而这个转换又必须查表编码。所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过 OutputStream() 类函数从而减少数据的编码转换;另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，并且只打印DO的基础要素和核心要素

　　裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加剧系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度

　　去组件框架：极致优化要求下，可以去掉一些组件框架，比如去掉传统的 MVC 框架，直接使用 Servlet 处理请求。这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度

　　高可用

　　流量削峰

　　答题：答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好地支撑瞬时峰值。MQ： 最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。过滤

　　Plan B： 为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底