秒杀场景兵器百解

什么是秒杀

短时间，大量请求，买一个(数量少的商品)，解决秒杀问题就是解决高并发的读和写
秒杀系统的目标就是：
稳：高可用，稳定的提供服务
准: 超卖，数据一致性问题
快: 高性能

架构原则

用户访问链路：
用户=>浏览器=> DNS=> CDN=> 负载均衡=> 网关=>服务=>IO

较少的用户端服务端的交互

数据要少：请求参数相应的参数要少，降低对网络带宽的占用，降低对CPU的消耗，对数据库IO要少（非必要信息不要来回传）
请求数要少：合并请求
路径要短：节点越多可靠性越低
依赖要少：花里胡哨的减少。优先级高的展示，低的去掉
要高可用(不要单点)：负载均衡，水平扩展，docker(服务+DB volume)

动静分离

数据分区：不同url、用户不同、不同浏览时长、地域不同、cookie(缓存信息)不同返回结果一致，可以叫做静态信息，可以放到CDN或者负载均衡(如Nginx 静态资源服务器)
同一个url访问同一详情类的数据，做CDN缓存放到离请求最近的缓存，浏览器处也能放缓存数据(把自己服务器的压力让用户分担一些)，服务器能做缓存的也要缓存guava cache、map、redis、文件缓存等。
总结：根据不同的用户类型做缓存。

热点数据

本来卖水果秒杀，系统都为水果服务结果衣服卖的比水果好 咋办

识别热点数据

监控追踪，根据用户访问、添加购物车、下单、统计分析(经验，BI)
发现热点数据：分析日志、添加队列、系统订阅。
分析日志：分析完日志得出热点商品投递到MQ，秒杀订阅该MQ，秒杀系统自动扩容

处理热点数据

lru算法，要做数据隔离 不让一台服务器影响到其它服务器
mq做削峰
分层过滤：验证码、答题
性能：
cpu频率，io(网卡、磁盘、IOPS)
RT(response Time)
程序的时间消耗：
1.程序的等待执行时间(几乎不影响)
2.执行的时间()
线程数计算：
粗略计算：2n+1
精细计算 ((线程等待时间+cpu执行时间)/cpu时间)*cpu核心数
最准确的还是先用公式计算个大概，然后多次压力测试得出结论。
数据一致性：
下单=>减库存 然后不购买
解决：1.预付超时回退 2.加一个中间状态支付中
扣库存加锁，解决ABA问题，zk+mysql乐观锁

秒杀的一些解决方案